What I've now done is give that URL with instructions on how to find it on
If it disappears, sure, I'll have to do something then. In the meantime, we
should try to be helpful.
> The whole point was to create an open documentation because there was
Yes, we are doing that. The purpose of references is so that people can
verify and double check what we've done and perhaps go further if they find
what we've done lacking.
And by the way right now, I am having trouble doing in the verify step.
After now geting cdtext.zip again I don't see these quotes from attributed
to Sony that are in there now.
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.
Added. Again it would help me if you did gave a diff output which is more
precise and less prone to my making a mistake.
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.
Changed. I suspect there is more regularization that should go on. I've not
been able to find in references places that mention to "Pack Types," or
"blocks" . It is possible "Text Pack" was supposed to refer to all of the
packs. Some of the pack types are text-oriented, and therefore Thomas
seems to have grouped them together when describing them. Given this, it's
possible where I wrote "Text Pack" it should probably Text-oriented Text
Packs" or something like this.
But since i don't see where this all comes from; I'm flailing here.
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
Changed in git and the change should also be on line.
> 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.
Thanks. I'd appreciate it. I'm interested in having good documentation out
there on this aspect, not interested writing it or spending back and forth
time on the mailing list.
You guys are more of the experts, not me; and you all definitely have more
interest in this than I do.
> 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:
>>> > Funny you should bring that up. After registering with Sony at I can't
>>> > 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
>>> > > 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 :)