Re: [Cdrdao-devel] START value for index 0 on toc extraction off by one error ?

[Thomas V. S. <th...@ap...>]

As a further data point, I did the following:

- read-cd cure.toc
- write cure.toc
- read-toc cure2.toc

ie, reading a cd, writing it again, then reading the written CD.

As you can clearly see from the attachments, there is an off-by-one
error on the frame calculation somewhere.  I'm going to assume it's in
the reading part after comparing with EAC.

In the bug tracker, I found
https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171

which looks like my bug.

I'll attach my findings there.

It would be nice to get this fixed, but meanwhile I'll work around it.
I hope I get told though when this gets fixed :) Otherwise my workaround
will get it wrong when it does.

Thomas



On Thu, 2009-07-02 at 23:19 +0200, Thomas Vander Stichele wrote:
> On Sat, 2009-06-06 at 19:08 +0200, Thomas Vander Stichele wrote:
> > Hi,
> > 
> > I noticed that cdrdao's toc extraction always lists the length of the
> > pregap as one frame shorter than EAC.  For example, on Muse's Black
> > Holes and revelations:
> > 
> > - cdrdao lists, for track 11:
> > // Track 11
> > TRACK AUDIO
> > NO COPY
> > NO PRE_EMPHASIS
> > TWO_CHANNEL_AUDIO
> > ISRC "GBAHT0500600"
> > FILE "data.wav" 39:23:53 06:07:22
> > START 00:00:37
> > 
> > - EAC has: 0:00:00.38 in the ui
> > 
> > Is it possible cdrdao has an off-by-one error here ? How can I verify
> > whether it's cdrdao or EAC getting it wrong ?
> 
> Anyone an idea ? I've verified this on two different drives, so I'm
> pretty sure I'm not seeing things.
> 
> Could someone try and confirm or deny ?
> 
> Thanks
> Thomas
> 

-- 
The only thing I understood where the comma's.
--
Flumotion - the only way to stream!
http://www.flumotion.net/