[Ardour-Dev] CD Marker Export in 2.8

[Sakari Bergen]

Andreas Ruge wrote:
> Hi all,
>
> I'd like to suggest a few small improvements for the CD marker
> export. I can provide a patch, but first would like to see, if there
> are any comments from others.
>
>   
Hi,

I implemented the new export dialog into 3.0 last summer, and I also 
took a look at marker export. Back then I had big troubles finding good 
specifications for the formats, but a quick googling around now gave 
better results...

There were some discussions about where to put the marker export 
functionality in 3.0 (in the UI), and I think the result was we should 
have a separate cd export dialog with less (or no) options for stuff 
that doesn't make much sense with cds (like sample rate), and more 
options for the stuff that matters. Hence there is no UI (yet) for 
marker file export in 3.0.

I did some refactoring of the marker export code, but IIRC didn't cause 
any changes to the actual output of the process. The "new" code resides 
in the ExportHandler-class (I think the functions are quite static, so 
they could be moved somewhere else).

Anyway, 3.0 needs work to be done here, and if you feel like taking part 
in doing it, it would be great :)
> I think that:
>
> 1. Cue sheets and TOC-files should both not link to their audio
> files by using an absolute path but rather just the audio file
> name--given that they both live in the same folder anyway.  This
> would allow e.g. a cue/wav pair to be moved to another location.  I
> can't see a reason, why we would want an absolute path here.
>
> 2. Cue sheet and TOC-file images should be name like this:
>
>     myimage.cue
>     myimage.wav
>
> This seems to common usage among other applications using this
> format.  Also there are (arguably broken) applications, that rely on
> this naming convention rather then parsing the cue sheet's FILE command.
>   
Sounds reasonable.
> 3. The cue sheet spec lists not only WAV and AIFF as file types, but
> also BINARY and MOTOROLA referring to raw audio files with little
> endian and big endian byte order respectively.  Ardour 2.8 should
> use these keywords in the FILE command, given that the user has
> chose that format (i.e. 44.1 kHz, 16 Bit, raw audio).  So far Ardour
> uses the string "raw (no header)".  This string might make sense for
> formats that are beyond the original spec anyway, but for example a
> cue/bin image (using the file type BINARY) is a reasonably well
> supported image format and Ardour should be able to export it.
>   
Last time I looked into this, I got frustrated about the fact that I 
couldn't find a _real_ specification for this. Some spec even had mp3 as 
a format, and that was just too much for me ;)
> 4. On an audio CD when you skip to a track, you actually skip to the
> track's "index 01".  Optionally a track can have an index 00 before
> that index 01, which is often referred to as a "pause marker" or
> sometimes even as the "end marker" of the previous track.  The span
> between Index 00 (if present) and index 01 is known as pre-gap, the
> counter on the CD player is supposed to count backwards in that
> span.  For the first track a minimum of 2 sec. pre-gap is mandatory,
> when filled with audio this is often called a "hidden track".
>   
Re-arranging markers so that you have valid pre-gaps and stuff like that 
are things that should be made part of the new cd export dialog.
> Cue sheets produced with Ardour list the index 00 even if the track
> has no pre-gap.  This is not a serious problem, as reading
> applications will most likely just ignore such an index command,
> still while we are at it, I'd like to see that fixed.
>
> 5. This is a small one, but I'd suggest that cue sheets are indented
> in what I think is the most common style among other applications:
>
>   TITLE "cue sheet example"
>   FILE "example.bin BINARY
>     TRACK 01 AUDIO
>       TITLE "First Track"
>       INDEX 00 00:00:00
>       INDEX 01 00:02:00
>     TRACK 02 AUDIO
>       INDEX 01 00:10:00
>
> Aside from these issues I found two small bugs in the filename
> mangling of the export dialog.
>   
These bugs are probably not present in 3.0, but I'd still be interested 
in hearing what they are

-Sakari-