IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
Flac Doesn't Let Me Embed This Cuesheet, What's wrong with it?
jcoalson
post Feb 10 2005, 16:24
Post #26


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



how is the cuesheet duration specified if there is no leadout?

Josh
Go to the top of the page
+Quote Post
Synthetic Soul
post Feb 10 2005, 16:30
Post #27





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Point taken.

You could ascertain whether the last index is feasible though. If the last index is smaller than the duration of the WAV then the cuesheet duration is valid.

Edit: I should reiterate that I wouldn't suggest any cuesheet checking by default.

However, if you are checking for sample/sector accuracy then it suggests that you would validate the cuesheet also. I tested this inference previously out of interest, and m0rbidini obviously assumed that it was already taking place - possibly because of the emphasis on accuracy between the WAV and cuesheet.

This post has been edited by Synthetic Soul: Feb 10 2005, 16:37


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
m0rbidini
post Feb 11 2005, 15:09
Post #28





Group: Members
Posts: 213
Joined: 1-October 01
From: Lisbon, Portugal
Member No.: 127



Meh, I had it "more or less right" the first time but then got confused. Anyway, my personal preference for any checks regarding this would be: "if the last index is smaller than the duration of the WAV then the cuesheet duration is valid" (like Synthetic Soul said and that's what intended to say but failed completely) or no checks at all.

cya
Go to the top of the page
+Quote Post
Synthetic Soul
post Feb 11 2005, 15:23
Post #29





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Actually, on re-reading, I think you said it just fine. I got a little confused by your post correcting yourself, that's all.

I see now that you are suggesting the "cuesheet-last-index test" as the only relevant test to make, and not suggesting that it is already in place.

And there was me thinking I'd come up with a good idea, when I'd actually just stolen yours. unsure.gif

Of course, if it turns out to be a bad idea, I will be quick to lay the blame squarely on your shoulders.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
smz
post Feb 12 2005, 01:23
Post #30





Group: Members
Posts: 602
Joined: 15-February 04
From: Venezia, Italia
Member No.: 12025



I would like to make with you all a sanity check of my ideas about this issue.

To briefly recall what the problem is let me state it in these terms:

"flac.exe refuses to embed a cuesheet when the number of samples of a WAV file to be encoded (PCM at 44.1Khz, 16bits/sample, dual channel) is not a multiple of 588, i.e. not a full CD sector".

The rationale behind this is that a cuesheet will mostly come from the ripping of a CD or an image prepared to be burned on a CD.

It also comes from the fact the when you embed a cuesheet in a flac file an extra virtual track is added to the CUESHEET metadata block. The offset of this track correspond to end of the file i.e. exactly to the "total samples" of that file. An information that BTW is already present in the STREAMINFO metadata block.

It must be noted that this virtual leadout track is by definition of 0 length and it is not present in the cuesheet format, the one we are used to from CDRWin and other applications that have adopted it to describe the content of CD and that we feed to flac to be embedded.

My feeling is that this last virtual leadout track is just a "hint" to help the decoding application to determine the length of the last (real) track.

Anyway we are talking about a "cuesheet" (although "not standard") and it will be embarrassing to have that offset specified at a point where it will be illegal (impossible) for a real CD.

My personal opinion is that this is not a big problem at all, because all burning application I know of can deal with a last track of the "wrong" length by appending the needed number of 0 samples to stuff the last sector.

A player, on the other hand, will have no problem stopping to decode at whatever sample number.

I think that one can pose itself the question of what to do at decoding time in case this special offset, the last sample, is not a multiple of a CD sector: stop decoding at that sample or stuff with 0 samples so that the decoding library will return a sector aligned stream? My personal opinion is that being FLAC a lossless decoder it should return a bit-identical stream to the input, so it should stop decoding where the original stream ended.

Beside that I really don't see any problem at all in the fact that this last (virtual, introduced by FLAC) track "starts" at a "wrong" boundary. (Maybe when you "pipe" multiple FLACs with cuesheet to a single burning session?? Is this possible with any application? Will it be screwed up by this situation??)

Does all that I said make sense? Have I missed some point? Am I too ignorant of the internals and thus ignoring something that shouldn't be?

About the fact that flac.exe (and metaflac as well) should check that the input cuesheet offsets falls inside the span of the file (a totally different issue), I can't agree more: that should be checked.

Cheers

Sergio

Edit: Spelling, comme d'habitude

This post has been edited by smz: Feb 12 2005, 01:35


--------------------
Sergio
Revox B150 + (JBL 4301B | Sennheiser HD430)
Go to the top of the page
+Quote Post
smz
post Feb 12 2005, 02:16
Post #31





Group: Members
Posts: 602
Joined: 15-February 04
From: Venezia, Italia
Member No.: 12025



One more consideration:

If foobar2000 easly accept an external cuesheet pointing to a "wrong length" WAV (or FLAC, for that matter) file, royally ignoring the CD-DA standard, that doesn't apply to a player, why should flac.exe instead refuse to encode ("play") such a cuesheet?

Sergio

This post has been edited by smz: Feb 12 2005, 02:18


--------------------
Sergio
Revox B150 + (JBL 4301B | Sennheiser HD430)
Go to the top of the page
+Quote Post
rjamorim
post Feb 12 2005, 03:24
Post #32


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (smz @ Feb 10 2005, 10:17 AM)
Correct. We are not talking about screwing up the cuesheet standard introducing the possiblity to add non frame aligned timestamps, not at all. We are talking about a lossless codec arbitrarily adding (virtual) data at the end of a stream. Not very lossless, IMHO.


It's up to the lossless decoder to decide what to do at the end if there's a misalignment. I would believe any sane decoder would just stop decoding no matter if the CUE claims there should be data ahead of the end. What would be the practical purpose of filling the decode/playback with zeroes anyway?

QUOTE
@rjamorim:
I think this fact should be evidenced in your "Which is the best lossless codec?" thread . Don't you?


I don't. I think it's completely outside of the scope of a lossless codec to decide whether to accept a CUE sheet or not based on the amount of samples.

What now, will FLAC also refuse to embed CUE sheets on tracks at 48khz? Or at 24 bit depth? Because these aren't CDDA for sure.

WavPack isn't anal about this subject because David doesn't try to know better than the user. He knows damn well audio editors can create cue sheets, completely misaligned and on audio tracks not following CDDA. He also knows that an user may have a wav+cue rip, decide to cut a part of the ending of the file (for ANY reason he deemed appropriate - David isn't judging) and then decided to embed the cuesheet. Samples will be missing at the end, but so what? I think the users are smart enough to take their own decidions. And even if they aren't, it's not up to the lossless codec to take that decision. That is a very arrogant and paternalistic behaviour, IMO.


QUOTE
And while I'm at that, though totally OT, I think that also the borked LA foobar component should be evidenced there.


I might make a note about it on the LA entry, but I won't put it on the cons. It's not the codec that is broken - it's the interface made to interact foobar and the decoder. If the decoder itself was broken, it would be a different story altogether...


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
rjamorim
post Feb 12 2005, 03:28
Post #33


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



...

This post has been edited by rjamorim: Feb 12 2005, 03:29


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
smz
post Feb 12 2005, 03:38
Post #34





Group: Members
Posts: 602
Joined: 15-February 04
From: Venezia, Italia
Member No.: 12025



QUOTE (rjamorim @ Feb 12 2005, 03:24 AM)
QUOTE
@rjamorim:
I think this fact should be evidenced in your "Which is the best lossless codec?" thread . Don't you?


I don't. I think it's completely outside of the scope of a lossless codec to decide whether to accept a CUE sheet or not based on the amount of samples.
*


I didn't explain myself well... I think that this cuesheet embedding issue should be accounted between the "cons"...

QUOTE (rjamorim @ Feb 12 2005, 03:24 AM)
QUOTE
And while I'm at that, though totally OT, I think that also the borked LA foobar component should be evidenced there.


I might make a note about it on the LA entry, but I won't put it on the cons. It's not the codec that is broken - it's the interface made to interact foobar and the decoder. If the decoder itself was broken, it would be a different story altogether...
*



I agree: just a WARNING

This post has been edited by smz: Feb 12 2005, 03:39


--------------------
Sergio
Revox B150 + (JBL 4301B | Sennheiser HD430)
Go to the top of the page
+Quote Post
rjamorim
post Feb 12 2005, 17:11
Post #35


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (smz @ Feb 12 2005, 12:38 AM)
I didn't explain myself well... I think that this cuesheet embedding issue should be accounted between the "cons"...


Well, I don't think the cons would be the right place, since it's not a problem in the codec itself - it's a frontend issue.

But I agree, a warning about the frontend being too anal would have its worth.

QUOTE
I agree: just a WARNING
*


Right smile.gif

I'll work on it ASAP. I'll add some more info to the table as well.


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
jcoalson
post Aug 24 2005, 01:27
Post #36


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



following up, this is changed in CVS, output now looks like:

CODE
[~/flac/bugs/ha/wave+cue/z]$ flac -0 --cuesheet=test_small.cue untitled.wav

flac 1.1.2, Copyright (C) 2000,2001,2002,2003,2004,2005  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

options: -P 4096 -b 1152 -l 0 -q 0 -r 2,2
test_small.wav: WARNING cuesheet "test_small.cue" is not audio CD compliant: CD-DA cue sheet lead-out offset must be evenly divisible by 588 samples
untitled.wav: wrote 3032350 bytes, ratio=0.454
[~/flac/bugs/ha/wave+cue/z]$


hopefully people will heed this warning... if you are ripping CDs and you get this, your rip was bad.

Josh
Go to the top of the page
+Quote Post
Synthetic Soul
post Aug 24 2005, 09:40
Post #37





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Thanks Josh.

As you say, it's up to the user to do with this information as they please.

Someone who really cares about rips will take notice - those that don't, won't.


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
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: 26th December 2014 - 23:01