opensubscriber
   Find in this group all groups
 
Unknown more information…

l : libcdio-devel@gnu.org 9 February 2012 • 1:32AM -0500

Re: [Libcdio-devel] CD-TEXT documentation
by Leon Merten Lohse

REPLY TO AUTHOR
 
REPLY TO GROUP




Hi,

I had some trouble to find it, too.
http://web.archive.org/web/20070204035327/http://www.sonydadc.com/file/cdtext.zip
I would rather not rely on this though because they might delete it
eventually.

The whole point was to create an open documentation because there was
none. The t10 drafts give some really interesting insights into some
structural aspects but it does not say much about the data. The Sony doc
helped a lot but is very incomplete, too. The sites that come up when
googling for CD-Text are either wrong or extremely superficial and most
of them just quote Wikipedia (which has an imho horrible article on
CD-Text).

Your documentation looks really good to me!
There is one thing, I would add to the genre section:
You can either specify a genre code or the supplementary genre
information (without the code) or both. Neither is mandatory.
The specification does not say whether the following genre packs hold
the two bytes, too or not. In fact even the two standard implementations
do not behave the same on this. CDRWIN adds it to every genre pack,
while the Sony tool does not. (or was it the other way around, Thomas?).
libcdio does compensate for this.

I would rather not call the 0x8f pack "Block Pack" but "Block Size
Information", "Block Size", "Block Information" or similar.
Also I would say
        3 : 3 -> CD-TEXT is copyrighted, 0 -> CD-TEXT is not copyrighted
rather than
        3 : libcdio source states: "cd-text information copyright byte"
            Probably 3 means "copyrighted", 0 means "not copyrighted
Actually this byte holds some more information (according to cdda2wavs
source code) about program area subchannel copyright (?) if I remember
right but not even the Sony tool, which was my and therefore libcdios
reference implementation, supports that.

I am going to update the CD-Text libcdio api documentation once I am
done fixing it.

Regards
Leon

On Wed, 8 Feb 2012 11:20:44 -0500, Rocky Bernstein wrote:
> On Wed, Feb 8, 2012 at 8:01 AM, Thomas Schmitt <scdbackup@gmx....>
> wrote:
>
>> Hi,
>>
>> > Funny you should bring that up. After registering with Sony at I
>> can't
>> find
>> > cdtext.zip on http://www.sonydadc.com
>>
>> We had to retrieve it from the Wayback machine.
>>
>
> Well, I registered then with Sony for no reason at all. I need to
> update
> the doc so someone else doesn't fall into that trap.
>
> I had looked on the Wayback  as well and couldn't find it. Do you
> have an
> exact URL?
>
>
>>
>> Similarly, the free PDFs of SCSI drafts have gone.
>> See yellow box on http://www.t10.org/drafts.htm
>> Prices for PDFs of the finalized specs have dropped to 30 USD per
>> doc.
>> (One would need SPC-3 and one of the MMCs. For CDs i'd advise MMC-3.
>>  Later versions do not have the annex about CD-TEXT.)
>>
>
> I'd prefer if we could find and use freely available docs. I have no
> problem using drafts rather than the final specification especially
> when
> they are the same in the areas we care about.
>
> If folks prefer to buy the final spec - okay. But in  OSF projects I
> work
> on, I would prefer not to put any pressure or advertising for
> non-free
> documents.
>
>
>>
>> > > 2.2:
>> > >
>> > > Should be coordinated with libcdio.texi @node  CDRWIN BIN/CUE
>> Format.
>> > > At least by mutual references.
>> > > (My .cue example is tested with wodim and cdrskin.)
>> > >
>>
>> > Not sure what you mean. If there are still problems let me know.
>>
>> Not problems. But there is a very sparse paragraph about CDRWIN .cue
>> in
>> libcdio.texi and there is the example in cd-text-format.html. Both
>> are
>> quite complementary and could take profit from the other.
>>
>
> Ok. Will look in to later.
>
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>



Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.