FLAC choices

[Philip Meyer]

I'd say it's definitely worth ripping each song as a separate file, and avoid CUE sheets. My reasons are:

1. Better mixes via MusicIP.
2. Better ReplayGain data (per-song) when playing random songs.
3. Better cross-application support (many apps don't like cue sheets).
4. Less time wasted re-ripping/validating if there are scratches on the disk.
5. CUE sheets don't support many tags. You can put anything in FLAC files per track, even custom tags and read with CustomScan plugin if necessary, but your options are constrained with CUE sheet data.
6. CUE sheets may need to be hand-modified if you move files around (if they contain absolute or relative paths that become invalid with folder restructuring).

[eq72521]

I only scanned the thread here so if someone already outlined what I do, I apologize for repeating.

I do file per track, appending the gaps to the end of the previous track. In addition, I save a CUE sheet (that I rename to have a TXT extension so SC will leave it alone) as if I'd ripped everything as a single track. In EAC this is the "Action -> Create CUE Sheet -> Single WAV File". If I ever need to generate the exact CD again (and I have a few times), I just need to stitch together all the individual WAV files into a single file with sox.

$ flac -d *.flac
$ sox *.wav Range.wav

After this, the CUE file (renamed back to have a CUE extension) and the stitched WAV file are usable in EAC, Nero, CDBurnerXP (I think), and probably a dozen other programs.

I toyed with doing one file per CD, but back when I started this (2004 or 2005) SlimServer support for CUE sheets wasn't quite where it seems to be now and, as Darth says, it is too late for me. This method also has the advantage of working seamlessly with Robin Bowes' flac2mp3.pl script for making an MP3 copy of one's music tree.

[radish]

If I ever need to generate the exact CD again (and I have a few times), I just need to stitch together all the individual WAV files into a single file with sox.

$ flac -d *.flac
$ sox *.wav Range.wav

After this, the CUE file (renamed back to have a CUE extension) and the stitched WAV file are usable in EAC, Nero, CDBurnerXP (I think), and probably a dozen other programs.

What advantage does that give you over just burning all the individual flacs in DAO mode?

[eq72521]

What advantage does that give you over just burning all the individual flacs in DAO mode?

It retains the precise gaps that were present in the original disc. Burning the individual flacs (presumably with gaps set to 0) would cause this information to be lost.

[radish]

It retains the precise gaps that were present in the original disc. Burning the individual flacs (presumably with gaps set to 0) would cause this information to be lost.

No it wouldn't, the gaps are encoded as silence on the end of the per-track files. You even said that in your own post...so I'm a little confused!

[cdmackay]

I'm trying some tests of my own, and the first odd thing I noted, is
there seems to be some transcoding going on, when I'm streaming a flac
file to an SBR. Can that be right?

I ripped a CD to a single flac file - just to try it - using XLD on the
Mac, if that matters, with a separate cue file.

SC sees it fine, and has no trouble with it, of course.

But I noticed some activity on my system, and I see the following
processes running (this is on Linux):


/usr/share/squeezecenter/Bin/i386-linux/sox -q -t wav - -t flac -C 0 -

/usr/bin/flac -dcs --skip=5:31.42 --until=9:10.02 --album.flac


This looks to me like flac is decoding the file to WAV, and passing it
to sox, which is turning it back into FLAC.

What is the point of this, and how do I avoid it, anyone know?


Might it be related to this snippet I see in the main window when a
track is selected?

Bitrate: 754kbps VBR (Converted to 705.6kbps ABR)

is this variable -> fixed bit-rate conversion the reason for the
transcoding?


thanks much for any comments.

[eq72521]

No it wouldn't, the gaps are encoded as silence on the end of the per-track files. You even said that in your own post...so I'm a little confused!

Well, burning the FLACs in DAO (or anything with no gaps) will make the disc *sound* the same as the original if you listen straight through, but the actual gap points (the information telling the player that a gap exists for a particular track) will be lost. What was on the original disc a pre-track gap for a particular track will forever be actual normal track information at the end of the preceding track, and every track will just have a pre-track gap of 0.

This mainly makes a difference in shuffle mode. In the original disc, the pre-track gap will be heard before the track being played or, on some players, not at all (because going to a new track in shuffle mode is treated the same as a seek whereupon the player begins play at INDEX 01). On the new disc burned in DAO mode without the aid of a CUE Sheet, the pre-track gap for a given track will be heard at the end of the preceding track, whenever that is heard. Because there is actually nothing about the pre-track gap definition that says it has to be of a certain length or that it must be silence, the difference is most clear on discs that make use of this and stray well outside the norm of a gap of silence between 0 and 2 seconds.

A good example is Comin' Back on The Crystal Method's debut album Vegas. It has about a 1.5 minute pre-track gap that has actual music (no jokes about CM, please). If I seek directly to or hit this track in shuffle mode, I don't hear that bit at all. If a copy were burned without the aid of a CUE Sheet, I'd hear this at the end of the preceding track (High Roller) every time that track was played, no matter what. Of course, this is also the behavior I get in my current setup where I stream FLACs to various SBs...

Also, many live performance CDs in which an emcee in present will have the emcee's introduction to each piece in the pre-track gap. On some CD players then, if you listen to the disc in shuffle, you'll never hear these introductions.

This lack of proper support for this aspect of CDs (plus lack of support for indexes beyond 01) is actually one of the things that I miss most about having moved to having all my music on a server.

[chill]

This lack of proper support for this aspect of CDs (plus lack of support for indexes beyond 01) is actually one of the things that I miss most about having moved to having all my music on a server.

For the benefit of the OP, and unless I've misunderstood this issue, I should point out that the FLAC-per-CD+CUE approach should not suffer from this problem. This makes me seem more zealous about this approach than I am, but the OP DID ask for all the pros and cons!

[Moonbase]

[…] lack of support for indexes beyond 01 […]

This bugs me (and probably every classical/live music lover). Unfortunately, it’d require hefty code changes, so we could only expect it in a future version. In the meantime, you might want to vote for bug 11168.

[radish]

Well, burning the FLACs in DAO (or anything with no gaps) will make the disc *sound* the same as the original if you listen straight through, but the actual gap points (the information telling the player that a gap exists for a particular track) will be lost. What was on the original disc a pre-track gap for a particular track will forever be actual normal track information at the end of the preceding track, and every track will just have a pre-track gap of 0.

This mainly makes a difference in shuffle mode.

Ahh gotcha. Makes sense, thanks for the explanation. I never use shuffle so I wouldn't have noticed!