IPB

Welcome Guest ( Log In | Register )

> foobar2000 General Forum Rules

This is NOT a tech support forum.
Tech support questions go to foobar2000 Tech Support forum instead.

See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
Converting FLAC to multitrack in another lossless format generates dif
Anakunda
post Nov 12 2012, 15:31
Post #1





Group: Members
Posts: 449
Joined: 24-November 08
Member No.: 63072



HI!!
Strangely after converting album in FLAC tracks to multitrack file in another format generates different tracks. Comparing the first track foobar complains about different length:

Differences found in 1 out of 1 track pairs.

Comparing:
"E:\xfer\download\Television - Marquee Moon (PBTHAL Vinyl Rip 2012)(Hi-Rez)\01 - See No Evil.flac"
"G:\music\Television - Marquee Moon [LP] {pbthal @ March 16th, 2012} (1977)\Side A.tak" / index: 1
Length mismatch : 3:58.517937 vs 3:58.520000, 22897722 vs 22897920 samples

Why is that and is it bug or limitation of internal tracks indexing?
Can I achieve same tracks lengths using temporary cuesheet somehow?
Go to the top of the page
+Quote Post
Gjorgjevski
post Nov 12 2012, 15:57
Post #2





Group: Members
Posts: 6
Joined: 17-October 12
Member No.: 103913



QUOTE (Anakunda @ Nov 12 2012, 15:31) *
Strangely after converting album in FLAC tracks to multitrack file in another format generates different tracks. Comparing the first track foobar complains about different length:

How was the ‘conversion’ done?
Go to the top of the page
+Quote Post
Anakunda
post Nov 12 2012, 16:03
Post #3





Group: Members
Posts: 449
Joined: 24-November 08
Member No.: 63072



Yes this was made using the middle option (Generate multi-tracks files)
Go to the top of the page
+Quote Post
lvqcl
post Nov 12 2012, 16:09
Post #4





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



That's a CUE sheet limitation.
Go to the top of the page
+Quote Post
Anakunda
post Nov 12 2012, 16:13
Post #5





Group: Members
Posts: 449
Joined: 24-November 08
Member No.: 63072



So there's no way how to convert files to multitrack exactly indexed?
I think CUEtools provide this functionality (not too sure) but sadly it only works for CDA.
Go to the top of the page
+Quote Post
Peter
post Nov 12 2012, 16:41
Post #6


foobar2000 developer


Group: Admin
Posts: 3275
Joined: 30-September 01
Member No.: 84



Cuesheet format stores timestamps with precision down to 1/75th of a second. You cannot have more accurate track split marks when using cuesheets, hence strange results you've noticed.
Go to the top of the page
+Quote Post
mjb2006
post Nov 13 2012, 00:27
Post #7





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



I don't understand. He's got an album side in a .tak file w/cue sheet. The cue sheet says track 01 index 01 starts at whatever point in the .tak (00:00:00 probably) and track 02 index 01 starts at some later point. The difference will be a multiple of 1/75th of a second, which for a presumably 96 KHz "hi-res" vinyl rip is going to be 1280 samples. 22897920 is indeed a multiple of 1280. Assuming the sample rate wasn't changed in the conversion to FLAC, why would the FLAC come up 198 samples short? foobar2000 says index 1 in the .tak is 22897920 samples, so why shouldn't it feed that many samples to the converter and why shouldn't he expect the same number of samples to show up in the resulting FLAC?

This post has been edited by mjb2006: Nov 13 2012, 00:29
Go to the top of the page
+Quote Post
Anakunda
post Nov 13 2012, 00:40
Post #8





Group: Members
Posts: 449
Joined: 24-November 08
Member No.: 63072



QUOTE (mjb2006 @ Nov 13 2012, 00:27) *
so why shouldn't it feed that many samples to the converter and why shouldn't he expect the same number of samples to show up in the resulting FLAC?


Not exactly....FLACs were cut exactly (non-CUE normalized) whích probably lead to CUEsheet rounding in resulting multitrack file.
The question is if multitrack file could use different indexing than by embeded CUEsheet, sample accurate. This however probably would be a foobar specific hack incompatible with anything other... rolleyes.gif
Go to the top of the page
+Quote Post
Kohlrabi
post Nov 13 2012, 09:01
Post #9





Group: Super Moderator
Posts: 1002
Joined: 12-March 05
From: Kiel, Germany
Member No.: 20561



QUOTE (mjb2006 @ Nov 13 2012, 01:27) *
The difference will be a multiple of 1/75th of a second, which for a presumably 96 KHz "hi-res" vinyl rip is going to be 1280 samples. 22897920 is indeed a multiple of 1280.
CUEs are meant to represent CDs, not provide chapter support for arbitrary media. Try using a real chapter format for anything non-CD.


--------------------
Audiophiles live in constant fear of jitter.
Go to the top of the page
+Quote Post
skamp
post Nov 13 2012, 10:39
Post #10





Group: Developer
Posts: 1409
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (jcoalson @ Apr 14 2007, 17:43) *
cuesheets for non 44.1 audio should use sample numbers instead of mm:ss:ff


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
Anakunda
post Nov 13 2012, 10:45
Post #11





Group: Members
Posts: 449
Joined: 24-November 08
Member No.: 63072



QUOTE (skamp @ Nov 13 2012, 10:39) *
QUOTE (jcoalson @ Apr 14 2007, 17:43) *
cuesheets for non 44.1 audio should use sample numbers instead of mm:ss:ff


Would this be posible with foobar? Dunno if assigning indexes as sample numbers is part of CUE standard?
Go to the top of the page
+Quote Post
mjb2006
post Nov 14 2012, 03:00
Post #12





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (Kohlrabi @ Nov 13 2012, 02:01) *
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.

QUOTE (Anakunda @ Nov 12 2012, 17:40) *
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":
CODE
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:
CODE
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.

This post has been edited by mjb2006: Nov 14 2012, 03:15
Go to the top of the page
+Quote Post
lvqcl
post Nov 14 2012, 04:24
Post #13





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



I still don't get it. Your original file is an album side, one long audio file.

No, original files are several FLACs and they were converted into single TAK + cuesheet.
Go to the top of the page
+Quote Post
mjb2006
post Nov 14 2012, 07:08
Post #14





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Ah OK, never mind then. Sorry for not getting that out of the original post.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd July 2014 - 04:29