Skip to main content
Topic: Going Lossless (Read 14657 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Going Lossless

Hi!

Here are my thoughts... How sound are they and can you advise me on which direction to take:

I've just bought a 120Gb HDD for storing "My Documents" on...  basically because I thought that for 50 pence per Gb it was time to go lossless.

I'd like to store all of my CDs in a lossless format and then transcode them to a lossy format when I want to listen to them on my portable player.  The theory being that as  audio formats evolve and portable storage increases I don't need to dig all my CDs out I can just revert to my lossless copies.  As ripping is for life not just for Xmas!

Moreover today when I transcode to alt preset standard for my MP3 Player, I sometimes find that I have say 60Mb left and it's not enough for an album, but in this scenario I would just on the fly transcode from FLAC (say) to ABR 160 MP3.

Which lossless gives the best tradeoff between overhead (I want to transcode regularly) and filesize.  I have been considering FLAC.  My other requirement is that the CODEC should still be supported in 10 years time!

Any views guys?

Cheers,
Fairy

Going Lossless

Reply #1
Quote
My other requirement is that the CODEC should still be supported in 10 years time!

Going lossless means you don't have to care anymore about the codec's future. You can transcode anytime, as often that you wish.

Going Lossless

Reply #2
Quote
Which lossless gives the best tradeoff between overhead (I want to transcode regularly) and filesize.  I have been considering FLAC.  My other requirement is that the CODEC should still be supported in 10 years time!

If you want it to be compatible 10 years from now, then I'd go with whatever lossless codec was available 10 years ago. 

Do you see the problem here in recommending something for 10 years from now?

Going Lossless

Reply #3
Quote
Going lossless means you don't have to care anymore about the codec's future. You can transcode anytime, as often that you wish.

Very true, once you see the end of your chosen codec coming, you can always switch your music to another ship, especially since your files are on a HD, not CD-R or DVD-R.
Anyway, in case you are still worried about future support, simply choose an open source one like Flac or Wavpack. If I were preparing for such a titanic endeavour, I would happily wait for Wavpack 4 to be out. It promises to be such a beast!

EDIT: Since you are going to transcode often, I would choose FLAC, if you don't mind the slightly larger file sizes. The superb decoding speed makes it ideal as a transcoding source IMHO.

Going Lossless

Reply #4
sure i do but you get the idea.  FLAC looks quite safe and has low CPU overhead for decoding which appeals.  And of course I could use the std from 10 years ago, PCM WAV ;-) and just compress the drive!  But ehm no.  Although ...

I'm thinking of using dbPoweramp/Sveta for transcoding and CDex for ripping (I may use EAC but I haven't found a way to get \Artist\Album\xxx directory structure without manual intervention.

Question:  ID3v2 tags for MP3 do the business what's the taging like in FLAC or should I look at something else?  Is there basic taging support?

Fairy

Going Lossless

Reply #5
Don't get fooled to think that 120GB is big when you talk lossless - I am sitting at 240GB with 2GB left 
And that is without having any mp3s of these albums!
Once you choose to go lossless I think you would find it difficult to just rip CDs into a lossy format after that.
As FautVoir says you don't have to worry about which codec - Lame -aps (-ape) should be fine for the forseeable future.
I think if you are talking lossless the main choices are monkey's audio (ape) and Flac (flac) - there are benifits to each and you should probably read up on each to determine which suits you better

Going Lossless

Reply #6
FLAC has its own tagging system (FLAC tags) which do the job nicely. They don't have an (obvious) max. size for the tags as ID3v1 does and IMO it's pretty fast.
Of course, if you use foobar2000, APEv2 is used seemlessly.

Going Lossless

Reply #7
I currently have 200Gb in total in my PC which should do me for another 12 months when I'll add a third HDD )

I still have to use my SATA channels 

So it's monkeys or FLAC... Hmm I'll go looking for info on APE and see if I can find a comparison!

Fairy

Going Lossless

Reply #8
APE compresses more than FLAC (about 20-30 MB saved per album). At high compression settings it's also faster. (FLAC -8 is quite slow and saves few kB with regard to -5). APE supports APL which are very useful if you are going to listen to the APEs directly.
FLACs strengths are its blazingly fast decoding speeds (excellent for frequent transcoding, APE), error-resilience (meaning that if a cluster goes bad, the file is still playable, contrary to APE, for instance) and open-sourceness, if you care about it.
Error correction for the two of them can be achieved by making a PAR2 of your encoded albums. Seeking appears to be the same for both to me using foobar2k (instant).
I would also consider Wavpack 4 in the future, which will boast error-resilience, fast encoding speeds and good compression, in addition to other goodies.

Going Lossless

Reply #9
I have 270 Gb FLACs. I started going losless 15 months ago. I have had A LOT of problems - some with FLAC alone, others with FLAC + foobar2000.

1. A known critical bug in metaflac 1.0.4 currupted several of my files. Josh was kind enogh to put the critical bug in a footnote somewhere on the site. Good thing I had a full backup or it would have been the end of FLAC.

2. Josh's linux binary cannot not tag with UFT-8. I had to spent days figuring out how to compile FLAC myself and write a conversion script. He knows it is broken and doesn't care.

3. foobar2000 issue #1 (fixed) - 0.7.0 somebeta crashed upon loading random FLAC.

4. foobar2000 issue #2 (fixed) - foobar2000 died horrible when opening non-FLAC file URL ending with .flac.

5. foobar2000 issue #3 (not fixed) - sometimes updating tag info takes 5 minutes.

6. foobar2000 issue #4 (not fixed) - tags are not read properly when loading file.


I am completely fed up with FLAC, but I am waiting for something better (with linux support) to come along. Might be Wavpack4.

Going Lossless

Reply #10
As long as your PC is relatively new (~1ghz), you could get away with using APE's -fast, -medium or -high presets.  APE -high will be 3% smaller than FLAC (~15-20mb per album) and decodes at under half the speed..  which might sound a lot, but that's 20x compared to 50x on a relatively new machine.

Check out http://web.inter.nl.net/users/hvdh/lossless/All.htm for yourself - I think this is still the only link you need for comparing size vs. speed for lossless codecs.
< w o g o n e . c o m / l o l >

Going Lossless

Reply #11
I have an Athlon XP 3200+ with 512Mb DDR 400 and did some experimenting with FLAC last night.  Rip times are SO fast!  Moreover the transcoding is the same as it is with ripping straight from CD, meaning the limiting factor for on the fly conversion is my CPU!  Well at least that's the case if going to LAME aps.  I'll have a look at the effect of going to ABR which from experience is a lot faster.

At the moment the open source nature of FLAC and the low decompression overhead make it attractive, I may try APE and see how I get on in the real world but it is not open source is it?

Cheers,
Fairy

Going Lossless

Reply #12
Quote
I may try APE and see how I get on in the real world but it is not open source is it?

It doesn't have an opensource licence but it's sources are available.

Going Lossless

Reply #13
Quote
1. A known critical bug in metaflac 1.0.4 currupted several of my files. Josh was kind enogh to put the critical bug in a footnote somewhere on the site. Good thing I had a full backup or it would have been the end of FLAC.

5. foobar2000 issue #3 (not fixed) - sometimes updating tag info takes 5 minutes.

sshd -

metaflac has always been a cheat for me - If you use Perl, you can use Audio::FLAC as an interface to the tag structure (writing tags is built in to the module as well.)

As far as fixing tags goes, if there's no space at the beginning of the file for extra tags, you essentially have to rewrite the entire file to get the tags to fit at the beginning of the file.  This is why the new encoder defaults to a 4k padding block to allow updates of the tags without rewriting the file.  This is an artifact of the way tags were set up, and also affects tag formats like ID3V2.

Going Lossless

Reply #14
Quote
metaflac has always been a cheat for me If you use Perl, you can use Audio::FLAC as an interface to the tag structure (writing tags is built in to the module as well.)

As far as fixing tags goes, if there's no space at the beginning of the file for extra tags, you essentially have to rewrite the entire file to get the tags to fit at the beginning of the file.  This is why the new encoder defaults to a 4k padding block to allow updates of the tags without rewriting the file.  This is an artifact of the way tags were set up, and also affects tag formats like ID3V2.

metaflac 1.0.4 works very well on FLAC 1.0.4 files. But it destroys random FLAC 1.0.3 files - and I had plenty of those.

The padding block is very nice and works fine with metaflac. It works very bad with libFLAC and foobar2000.

Going Lossless

Reply #15
Well I use WMA Lossless myself since it is very easy to use the files in Windows XP MCE.... but the Microsoft in the label tends to discourage many people......

Going Lossless

Reply #16
Quote
My other requirement is that the CODEC should still be supported in 10 years time!

Ten years is a long time.  The only safe way would be gzip (or plain ZIP) WAVs.  Then, tag by file name.
When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute--and it’s longer than any hour.  That’s relativity.
-- Albert Einstein

Going Lossless

Reply #17
No doubt it is probably a good bet that anything Microsoft may well be supported in ten years time if the Windows platform keeps selling?

Going Lossless

Reply #18
I'm also going lossless using FLAC, but so far have been ripping the whole CD as individual tracks.

I have the following aims:

1. CD Backup - I want to be able to reconstruct the CD fully from the FLAC file(s).
2. Transcoding to MP3 and other formats, as and when I need them.

So with that in mind, should I in fact be using the "extract full image with CUE sheet" option in EAC? What am I losing by not doing this? (track gaps I know, but which my CDs rarely have).

I know that foobar will happily play the individual tracks from the CUE sheet, but will it use the information in the FLAC tags + CUE sheet for tracknames to create MP3 tags when transcoding to individual tracks?

Also I assume this approach would be more risky with respect to file corruption, although its been mentioned that FLAC is quite good in this respect. Is PAR and option here (I don't have much experience with PAR, so any links/info appreciated).

Going Lossless

Reply #19
Flac is not platform specific. Hopefully 10 years from now you'll want to move away from Windoze, and as *Nix, OS X, etc can all read Windows drives in Flac your music will be safer and compatible.

Going Lossless

Reply #20
Who cares if FLAC does not exist anymore in 10 years from now ? If you keep the current binaries, you will be able to decode your FLAC files to whatever format you like then ... even if the whole internet disappears (might be some wishful thinking in some RIAA executive's wet dreams) ...
The name was Plex The Ripper, not Jack The Ripper

Going Lossless

Reply #21
Quote
APE compresses more than FLAC (about 20-30 MB saved per album). At high compression settings it's also faster. (FLAC -8 is quite slow and saves few kB with regard to -5).

I'm not sure how the numbers translate as I use dbpoweramp as the front end and get choices of something like low-medium-high.  The difference in file size between medium and high is miniscule, but there is a big difference in encode time, so I go medium.  The encode speed with medium is SO FAST that I think ripping to FLAC is faster than ripping to wav because of the reduced disk I/O.

Test a couple of CD's with the software you plan to use to verify that everything works ok especially with tags.  I guess there is some flexability with tag names like maybe "track" vs "tracknum" so sometimes I've had the track number get lost in the process of flac->lossy.
If you keep the track number imbedded in the file name (ie "01-songtitle") then the songs should still play in order plus a tagging program could recover it if needed.

If you are going to always encode on demand to fill your player you could consider Xing.
A lot of folks hate it, but you can bump the bit rate up.  Again, its big advantage is speed..
maybe 1 minute to encode a whole album on my ~2.5 ghz p4.  If you are encoding on-demand the extra speed over lame is probably worth it.

Going Lossless

Reply #22
Quote
Who cares if FLAC does not exist anymore in 10 years from now ? If you keep the current binaries, you will be able to decode your FLAC files to whatever format you like then

Ten years is a long time for code rot to set in.  WIll intel bother with x86 compatibility after a couple of generations of 64 bit processors?  At this time can you count on all the old windows 3 (or less!) programs from 10 years ago to just come up and run on XP?

But we aren't talking about walking away for 10 years.. you will have time to transcode to something more current.  The biggest concern might be those proposals to enforce DRM in the CPU hardware.... no audio/video processing at all without authenticatiion of DRM compliance.

Going Lossless

Reply #23
Quote
Quote
My other requirement is that the CODEC should still be supported in 10 years time!

Ten years is a long time.  The only safe way would be gzip (or plain ZIP) WAVs.  Then, tag by file name.

FLAC will be around 10 years from now for all the same reasons that gzip is still around.

Josh

Going Lossless

Reply #24
I'm glad to hear that. On OS X there is nothing to compare to it.

 
SimplePortal 1.0.0 RC1 © 2008-2020