Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Any reasons NOT to use FLAC? (Read 16359 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Any reasons NOT to use FLAC?

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?

Any reasons NOT to use FLAC?

Reply #1
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.

Any reasons NOT to use FLAC?

Reply #2
+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.

Any reasons NOT to use FLAC?

Reply #3
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.)

Any reasons NOT to use FLAC?

Reply #4
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


Any reasons NOT to use FLAC?

Reply #5
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).

Any reasons NOT to use FLAC?

Reply #6
I used EAC and REACT to rip to FLAC and LAME mp3s in the past.  Worked perfectly.
CK

Any reasons NOT to use FLAC?

Reply #7
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.

Any reasons NOT to use FLAC?

Reply #8
REACT2 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.

Any reasons NOT to use FLAC?

Reply #9
Heh, -1 to myself for not checking the wiki first.  Thanks.


Any reasons NOT to use FLAC?

Reply #11
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.
FLAC -2 w/ lossyWAV 1.3.0i -q X -i

Any reasons NOT to use FLAC?

Reply #12
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?

Any reasons NOT to use FLAC?

Reply #13
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.

Any reasons NOT to use FLAC?

Reply #14
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)

Any reasons NOT to use FLAC?

Reply #15
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.  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.)
FLAC -2 w/ lossyWAV 1.3.0i -q X -i

Any reasons NOT to use FLAC?

Reply #16
Quote from: garym link=msg=0 date=
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.

Any reasons NOT to use FLAC?

Reply #17
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
Creature of habit.

Any reasons NOT to use FLAC?

Reply #18
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.
FLAC -2 w/ lossyWAV 1.3.0i -q X -i

Any reasons NOT to use FLAC?

Reply #19
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.

Any reasons NOT to use FLAC?

Reply #20
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
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.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

Any reasons NOT to use FLAC?

Reply #21
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

Any reasons NOT to use FLAC?

Reply #22
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?

Any reasons NOT to use FLAC?

Reply #23
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?