Last year - when I didn't know any better - I decided to "archive" my entire CD collection as high-quality MP3s. Now that I realize archiving with a lossy encoder is a very bad idea, I'm going back to do it the right way.
I'm planning to use FLAC since it's free, seems to have pretty wide support, and the version of LAME I use for MP3 encoding supports FLAC inputs.
Are there any good reasons NOT to go this route:
CD --> Exact Audio Copy (WAV) --> FFmpeg (FLAC), retained
FLAC --> LAME (MP3), retained --> MP3Gain --> album art embedder
For example, is there any way to rip CDs directly to FLAC with EAC? If so, would it be possible to simultaneously create the FLAC and MP3? Will I be able to pass the album art (and other ID3 tags) from EAC to FLAC to LAME?
By all means skip the intermediate wav file and go directly to FLAC.
There are tools to create both FLAC and MP3 simultaneously, but that really doesn't save you that much over creating the FLAC files and then bulk encoding them to MP3.
Since you are starting a fairly large task, I would recommend that you first take a look at dBpoweramp. It's not free, but it may save you some time in the long run.
+1 on dbpoweramp. Excellent for ripping and metadata (tagging) sources, including high quality artwork. Can also do bulk conversion of your FLAC files to mp3 (or other lossy files). Best $38 I ever spent.
Thanks for the tip on dbpoweramp; I've never looked at it. Does it have a built-in method for minimizing errors on badly scratched CDs like EAC does? (Aside from AccurateRip, which I would assume they both can use.)
Thanks for the tip on dbpoweramp; I've never looked at it. Does it have a built-in method for minimizing errors on badly scratched CDs like EAC does? (Aside from AccurateRip, which I would assume they both can use.)
yes. secure ripping, ultrasecure, use of Accuraterip, etc. I'd say the two most recommended secure rippers are EAC and dbpa. (I could be wrong, but I thought that Spoon, creator of dbpa, is the creator or accuraterip as well.)
and by the way, ripping to FLAC is a good idea in my opinion. I'm about half way through ripping my ~10,000 CD collection, using dbpa.
you'll want the reference edition, and there is a free trial.
http://www.dbpoweramp.com/cd-ripper.htm (http://www.dbpoweramp.com/cd-ripper.htm)
Mentioning free ones, foobar2000 and CueTools/CueRipper use AccurateRip as well and they are perfectly fine with encoding/transcoding.
I like CueTools a little better than foobar2000 just for CD ripping because of the EAC log that it creates (and the Cue sheet if you need it).
I used EAC and REACT to rip to FLAC and LAME mp3s in the past. Worked perfectly.
CK
I used EAC and REACT to rip to FLAC and LAME mp3s in the past. Worked perfectly.
CK
What's REACT? Sorry, I'm still playing catch-up here.
REACT2 (http://wiki.hydrogenaudio.org/index.php?title=REACT) is a plug-in for EAC that allows you to simultaneously rip CDs into multiple formats.
Sadly, it is no longer actively developed and does not work with new versions of EAC.
Heh, -1 to myself for not checking the wiki first. Thanks.
Probably the most common method was not explicity mentioned: rip to flac via EAC, convert to lossy as needed.
http://freac.org (http://freac.org) is an excellent tool, and is also able to encode to Vorbis, AAC, WMA, and a quirky speech-oriented codec called Bonk (which I haven't seen supported by any players, AFAIK.) I use it daily.
Another reason to switch from MP3 to FLAC: it turns out my portable audio player, which is a Blackberry business phone, natively supports both FLAC and OGG files. Who knew?
OK, a follow-up question: I'm still learning about all the commandline options etc. available with FLAC. Right now, I'm planning to use -8 (the strongest compression available), because I don't care how long the music takes to compress; I'd rather compress it as tightly as possible.
But, I don't want to compress it so much that some players have trouble playing it. Is it possible to compress a FLAC so tightly that a system has trouble streaming it?
Another reason to switch from MP3 to FLAC: it turns out my portable audio player, which is a Blackberry business phone, natively supports both FLAC and OGG files. Who knew?
OK, a follow-up question: I'm still learning about all the commandline options etc. available with FLAC. Right now, I'm planning to use -8 (the strongest compression available), because I don't care how long the music takes to compress; I'd rather compress it as tightly as possible.
But, I don't want to compress it so much that some players have trouble playing it. Is it possible to compress a FLAC so tightly that a system has trouble streaming it?
In the past I've had trouble with a few players dealing with -8 FLAC files. But these were 24/96 files as well. And in my case, these players no longer have this problem due to firmware upgrades. I personally use -5. No good reason, but the file size difference between -8 and -5 is almost nothing, and in the past I had no issues with my problematic player when using -5.
seems odd to use FLAC on a blackberry. Maybe create FLAC files for home and archival use. Then create a mirror of lossy files (OGG?) for use on blackberry. I do this (FLAC for home, mp3 copies for portables)
The difference in encode/decode time and the absolutely negligible difference between -8 and -5 compression makes -5 a no-brainer for me. You should definitely take a look at the comp ratio comparison charts.
If you really want to get the tightest compression possible while retaining transparency, look into lossyWAV (http://www.hydrogenaudio.org/forums/index.php?showtopic=90104). Otherwise, as Gary suggested, Vorbis is the way to go for portable usage. Smaller files, fewer resources needed for decoding, and at q6, lossless stereo channel coupling (and I don't think I've ever ABX'd a q6 from a lossless reference.)
Stuff
Yeah, I probably won't actually play FLACs on the go - but it's nice to have that option in case I get lazy and decide not to create MP3s for future albums.
The difference in encode/decode time and the absolutely negligible difference between -8 and -5 compression makes -5 a no-brainer for me. You should definitely take a look at the comp ratio comparison charts.
Wow, you're right. Triple the encode time (-V8 versus -V5) for 0.4% better compression? That hardly seems worthwhile.
I also noticed that -V5 had the least decode time of any of the modes - even better than -V0. That's pretty surprising.
In reality, I'll probably do some testing and choose a compression mode that allows FLAC to take roughly the same amount of time to compress as it takes for EAC to rip a CD.
Otherwise, as Gary suggested, Vorbis is the way to go for portable usage. Smaller files, fewer resources needed for decoding,
(emphasis mine).
Do you have a cite for that?
Now Rockbox may not be the end-all-be-all of decoders, but Vorbis takes 2-3x as much CPU to decode as FLAC on ARM. I'm quite curious if you have better numbers.
http://www.rockbox.org/wiki/CodecPerformanceComparison (http://www.rockbox.org/wiki/CodecPerformanceComparison)
Do you have a cite for that?
Good call, I hadn't seen that link. I was going by my experience monitoring playback CPU performance in foobar, which was by no means controlled.
Again, FLAC encoding time is basically irrelevant.. You only encode 1 time, and I don't know about your machine but even at -8 it encodes faster than my drive can read the CD. Since that is the case the difference in encoding speed between -0 and -8 means nothing since either way I'm waiting for the CD drive.
Decoding time for any FLAC level is very fast and efficient, to the point that the differences are not enough to care about.
Here is the decode time, on a single core of an AMD A6-3650 CPU of a 16/44.1 23 minute file compressed at -8:
real 0m3.743s
user 0m3.412s
sys 0m0.296s
3.7 seconds.. to fully decode a 23 minute song. I have to say I no longer care about FLAC decode speed.
While I do love Vorbis and use it everywhere I can, it takes a lot more heavy lifting to decode.. The same song as above, decoded on the same machine from Vorbis -q6:
real 0m7.264s
user 0m5.748s
sys 0m0.820s
Again, pretty fast but that illustrates it's basically double the work to decode the Vorbis file versus the FLAC.
For reference here is the same song, decoded from lame -V3 using lame on the same machine:
real 0m9.237s
user 0m8.997s
sys 0m0.236s
You draw your own conclusions from that.
Now Rockbox may not be the end-all-be-all of decoders, but Vorbis takes 2-3x as much CPU to decode as FLAC on ARM. I'm quite curious if you have better numbers.
http://www.rockbox.org/wiki/CodecPerformanceComparison (http://www.rockbox.org/wiki/CodecPerformanceComparison)
FLAC seems to have the least CPU intensive decoding of all in most of the players listed. Nice to see such a comprehensive comparison of decoders on different hardware.
Thanks for the tip on dbpoweramp; I've never looked at it. Does it have a built-in method for minimizing errors on badly scratched CDs like EAC does? (Aside from AccurateRip, which I would assume they both can use.)
dBpoweramp is very good on that. But make sure you have a drive that supports C2 error pointers. And, you cannot count on them passing through USB (or Firewire ... I have a device where EAC manages to get C2 and dBp doesn't) – if you want an external drive, use eSATA.
I have been using dBpoweramp for years. Since then there is a new gun in town too, namely CUERipper. I would have given that a serious consideration if I were to start the job over again. Feature table (a bit outdated): http://wiki.hydrogenaudio.org/index.php?ti...n_of_CD_rippers (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers)
OK, I've finally settled on ripping directly to FLAC via EAC, and then following up with a FLAC-enabled version of LAME. But I have two questions before proceeding further, both on metadata:
(1) Is there a list somewhere of all the tag options (TOTALTRACKS, etc.) that FLAC supports? I haven't had any luck finding one.
(2) What's the best way to batch convert from FLAC to MP3 via LAME, preserving (sub)directory structure, FLAC tags (as ID3 tags) and album art?
1. FLAC supports Vorbis tags so put what you want in there, it's up to the player to decide what to do with them and how to display I guess
2. If you're doing batch conversion you'd be far better using something like foobar as it'll do all this for you It won't copy album art unfortunately (or at least the folder.jpd) which is what pushed me to dbPoweramp. I guess it's possible you could do that via some other method?
(1) Is there a list somewhere of all the tag options (TOTALTRACKS, etc.) that FLAC supports? I haven't had any luck finding one.
http://wiki.xiph.org/VorbisComment#Recommended_field_names (http://wiki.xiph.org/VorbisComment#Recommended_field_names)
I guess it's possible you could do that via some other method?
I guess that's the main reason why I'm still in the Apple ecosystem, using iTunes to manage my iPod and lossy library. Embedding art is something I deal with manually and only as needed when the iTunes store can't do it for me.
re: embedding artwork. One of the things I like about dbpoweramp, is that I can batch convert my FLAC files to mp3 (or other lossy) and retain all metadata AND artwork. And I can have it automatically take my cover.jpg or folder.jpg artwork files in each album folder (which might be as large as 1000x1000) and automatically resize these to something like 300x300 before embedding the art in the mp3 files.
2. If you're doing batch conversion you'd be far better using something like foobar as it'll do all this for you It won't copy album art unfortunately (or at least the folder.jpd) which is what pushed me to dbPoweramp. I guess it's possible you could do that via some other method?
Foobar also loses embedded cover art.
The post you quoted already says that.
Don't forget, TAS says FLAC is bad
But, I don't want to compress it so much that some players have trouble playing it. Is it possible to compress a FLAC so tightly that a system has trouble streaming it?
FLAC needs approximately the same resources to decode a -8 stream as a -5 (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=DecodeRate&Desc=1). So if you use the official encoder, and stay away from the --lax switch (http://flac.sourceforge.net/format.html#subset), you should be fine. (Except some devices have been reported not to conform, although off the top of my head I don't remember which, and a brief web search does not indicate it is any Blueberry.)
FLAC needs approximately the same resources to decode a -8 stream as a -5 (http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=DecodeRate&Desc=1). So if you use the official encoder, and stay away from the --lax switch (http://flac.sourceforge.net/format.html#subset), you should be fine. (Except some devices have been reported not to conform, although off the top of my head I don't remember which, and a brief web search does not indicate it is any Blueberry.)
Yep, I've had absolutely no problems - other than some brief static/jitters at the start of playthrough--on my Blackberry so far with -8 compression. (I even added -p on top of it, and am considering adding -r 7 or -r 8.) Decode time has been < 2 seconds per song. I can definitely live with that.
P.S. I'm not sure what a Blueberry is but I want one
(1) Is there a list somewhere of all the tag options (TOTALTRACKS, etc.) that FLAC supports? I haven't had any luck finding one.
http://wiki.xiph.org/VorbisComment#Recommended_field_names (http://wiki.xiph.org/VorbisComment#Recommended_field_names)
Document which helped me the most to make good decisions for tagging
is not available anymore, but some good soul made it available online again:
Ogg Vorbis (and FLAC) Comment Field Recommendations (http://www.legroom.net/2009/05/09/ogg-vorbis-and-flac-comment-field-recommendations)
Thanks for the tips; those links proved to be extremely useful. They also helped me find a couple of errors in EAC's default FLAC commandline
Which errors are those?
Which errors are those?
Disregard. I was unable to reproduce the error just now.
Originally, the problems were
1. The %albuminterpret% tag was being used for both the BAND and the ALBUMARTIST tags
2. %composer% was being used instead of %albumcomposer% for the COMPOSER tag
3. The syntax for the album picture tag (%hascover% section) was incorrect, and resulted in an error code from FLAC
However, since I can't reproduce them now, it's obviously due to something other than EAC. Maybe I made the mistakes myself or copied a suggestion from somewhere in the HA forums.