Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 10/04/12 13:36, jeff welty wrote:
> Hi Brian,
>
> No problem on the questions, questions are always good. Things get
> better when people are asking questions :-) In fact, I just caught
> another tiny bug because you asked this question.
>
> Tracks can start at any arbitrary position in the wavefile, cdrdao is
> just going to start copying data at that exact position in the wavfile
> to the CD. It is the length of the track that is restricted to multiples
> of 588 bytes.
>
> The logic in GWC for creating the cdrdao toc file goes like this:
>
> 1) The track start position will always be *exactly* at the song marker
> or at 0 in the case of the first track if you use
> the non-paired markers method.
>
> 2) compute the requested length of the track requested by using the next
> song marker or last audio sample if no more song markers.
>
> 3) round the requested length to the nearest 588 sample block
>
> 4) output the start position, and the rounded length to the toc file.
>
> The logic was set up like this because I though in most cases it was
> probably more important to get the start of the track positioned exactly
> where the user wanted it, and take the rounding error at the end of the
> track. The worst case would miss the song marker at the end of the track
> by 0.0067 seconds, probably not noticeable ;-)
> ---

Your explanation is very interesting.

My CD player is quite old and fussy about disks adhering to the original 
standards, but most of my CD's play OK. However, it is temperamental 
about playing some of those I made about 18 months to 3 years ago. I 
have always thought this problem was a combination of [media quality + 
writer quality + writer speed].

My more recent disks are almost always accepted first time. I wonder 
whether the "old disk" problem has something to do with the old version 
of gwc, which was happy to write a toc that didn't put tracks on 
boundaries of 588 samples? Perhaps a newer version of cdrdao has logic 
to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer 
firmware handles the toc more gracefully than the drive I used before?

Whatever the reason, my current production procedure generates playable 
CD's from the non-rounded tocs that I've edited manually, although other 
people might not be so lucky.

> I just noticed all your track lengths are odd numbers. Not good, because
> multiples of 588 must be even numbers. The code is outputting the length
> as (start - end), which is wrong, it should be (start-end+1). I wonder
> what cdrdao does with that, does it truncate or round the length. It
> could cause the actual track length to be 0.018 seconds shorter than
> desired in the worst case if it truncates. Still not noticeable, but
> still wrong.

Are you intending to release a patch that fixes both problems? If yes, 
would you like me to test it? Would you like me to add it to my ubuntu 
bug report when I mark its status as "patch available"?

> Thanks for your question!
> Jeff

One more question while you have the logic in your mind... why doesn't 
gwc deal with this boundary-rounding issue at the time it is creating 
the individual song marker? As you said, 588 samples is only 18 
milliseconds, so no harm would come if it were to enforce alignment of 
the new marker on a 588-sample position. Then, if you tried to drag the 
marker along the recording, it could just jump to the next valid 
position... but perhaps that is more complex and not worth the effort of 
implementing?

Regards,

Brian