Re: [Gwc-general] Invalid cdrdao toc file

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

On 09/04/12 23:51, jeff welty wrote:
> Hi Brian,
>
> I didn't get any new toc files in your message...
>
> I have tried both methods for creating the toc files, and it works
> perfectly for me.
>
> Are the differences you are seeing less than 588 samples? If so, that is
> expected because of the restriction that cdrdao tracks have to be
> multiples of audio blocks in length.

Sorry, Jeff! When I sent the last email I forgot to include the toc file 
built by your new version of markers.c. It is in-line at the end of my 
comments.

Following your advice, I checked the differences and can see they are 
smaller than 588 samples, i.e. the two "gaps" are 262 and 76 samples 
respectively.

I apologise for doubting you. You had mentioned this restriction earlier 
but I had forgotten it.

I /thought/ you meant gwc would always start a new track on a boundary 
that is a multiple of 588. I grepped the source for 588 and found it 
only only in markers.c, defining the constant SONG_BLOCK_LEN. I could 
only find that constant used in two routines - move_song_marker and 
mark_songs. Both routines appear to be rounding the song marker 
boundaries to make them multiples of 588.

I don't currently have a debugging environment to follow the logic any 
deeper, but my calculator says /none/ of the sample counters in the new 
toc are multiples of 588 (except zero, of course).

I apologise for being a nuisance, but would you mind explaining to me 
how the rule has been applied in this particular case?


CD_TEXT {
    LANGUAGE_MAP {
       0: EN
    }
    LANGUAGE 0 {
       TITLE "The Doors"
       MESSAGE "Brians clean test"
    }
}
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 1"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 0 38342303
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 2"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 38342565 28204595
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 3"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 66547236 50606219

> Jeff
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Monday, April 9, 2012 2:40 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 08/04/12 23:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > Thanks very much for the more detailed info. I was able to reproduce the
>  > problem, and it is one nasty bug. I guess everyone must've switched over
>  > to using the song marker pairs. BTW, the marker pairs idea allows you to
>  > have gaps between songs, some lead-in audio (like when the the needle
>  > hits the vinyl ;-) ), and some trail out audio. It gives you more
>  > control on what segments of audio you want to appear on the CD tracks.
>  >
>  > Another bit of important trivia, audio tracks must be integral numbers
>  > of audio blocks, which are 588 samples in length, so if you are doing
>  > math with song markers, you'll find small differences because GWC will
>  > create the cdrdao file with the track lengths to the nearest audio block.
>  >
>  > I have patched up the markers.c source code, and it is attached.
>
> Sorry to bring bad news, Jeff, but I have just built and tested your new
> source module. It looks to me as if you have nearly fixed the bug, but
> there is still a bit more to do.
>
> It seems to me that you haven't disabled the marker pair "track
> separator logic" and so the toc is not inclusive of every sample...
>
> i.e. start_track_n+1 != (start_track_n + length_track_n)
>
> Here is the toc built by your new code using the same wav and .gwc file
> as my test files below. You should compare it to the toc I built by hand
> to see what I think ought to be the "right answer".
>
> I won't start debugging your code unless you are too busy to do it
> yourself - I am sure you are so familiar with it you'll come up with a
> fix in a fraction of the time it would take me!
>
> Regards,
>
> Brian
>