Converting FLAC to multitrack in another lossless format generates dif
Reply #11 – 2012-11-14 02:00:38
CUEs are meant to represent CDs, not provide chapter support for arbitrary media. In a lossless-to-lossless conversion, foobar2000 should not have any trouble producing a file with the same sample count as appears for that item in the playlist. Everyone is getting hung up on the idea of it being a cue sheet, but it shouldn't matter. And my testing below shows that foobar2000 works fine in this regard; when the cue sheet is loaded into the playlist, the track duration estimates take the sample rate into account, and when the converter generates per-track files, they have the same durations, as expected.FLACs were cut exactly (non-CUE normalized) whích probably lead to CUEsheet rounding in resulting multitrack file. I still don't get it. Your original file is an album side, one long audio file. It has no track structure other than what is defined by the cue sheet, right? The cue sheet must be something like this: TRACK 01 AUDIO INDEX 01 00:00:00 TRACK 02 AUDIO INDEX 01 03:58:39 ... 03:58:39 = 238.52 seconds. At 96000 samples/second, that's 22897920 samples. It is totally reasonable to expect foobar2000 to put that many samples into the file it creates for track 01. There's no rounding, no reason it should come up 198 samples short. Example: 1. create a 15-minute "album side":sox -n -b 24 -r 96000 -c 2 triangle_24_96_15m.flac synth 900 triangle 200 2. create a cue sheet to split it into 2 tracks:PERFORMER "test" TITLE "pink noise" FILE "pink_24_96_15m.flac" WAVE TRACK 01 AUDIO INDEX 01 00:00:00 PERFORMER "test" TITLE "first track" TRACK 02 AUDIO INDEX 01 03:58:39 PERFORMER "test" TITLE "second track" 3. load the cue sheet into foobar2000: If you select just the first track, you'll see it has duration 3:58.520 (22 897 920 samples), as expected: 4. convert the tracks to separate files: If you then load the created files into foobar2000, you'll see they are exactly the right length...22897920 samples in [01] test - first track.flac ... It works the same even if I use an embedded cue sheet. So unless there's a bug in the TAK reader (I only tested with the source file being FLAC), there's something you're not telling us here. What exactly are you doing to produce a track with fewer samples? Is it exactly this same process, but with a TAK file as the source? I would consider it a bug if the converter isn't getting the right number of samples out of foo_input_tak.