The ITTS CD-Text myth

Wikipedia says CD-Text would be “stored in a format compatible with Interactive Text Transmission System (ITTS)” . But is it actually true?

Known differences:

  • Language Codes: Are specified in CD-Text and unspecified in ITTS, i.e. 0x00 is default language on ITTS and Unknown/non-listed language in CD-Text. In other words, CD-Text does know what English is, for ITTS it is just the nth language.
  • Packet size: CD-Text packages “consist of a 4-byte header, 12 bytes of payload, and 2 bytes of CRC”, “ITTS packets have a length of 48 bytes: an 8 byte header
    and a 40 byte TEXT or DATA string.”
  • Fields: ITTS has no predefined fields like Album, Artist and so on but arbitrary text, CD-Text does not have any arbitrary text
  • Location: CD-Text is defacto only stored in the Lead-In, ITTS is stored parallel to the content
  • Synchronisation: Due to the location, CD-Text natuarally has no synchronisation, except showing the fields of the current track, ITTS has synchronisation.
  • Copy Protection: CD-Text has a flag for copy protecting the text, ITTS does not have anything similar

Known similarities:

  • Storage in some kind of subchannels
  • ISO 8859-1 as basis for the text-encoding

To conclude, in my opinion two non-related standards except a similar era and use-cases. By far the most common citation of ITTS/IEC 61866 is totally off.

3rd gen DCC text could be similar and/or related to CD-Text, though.

ITTS could be stored in the R through W-subcode on CDs which is otherwise only used by CD+G, CD+MIDI and as mentioned by CD Text during the Lead-In. Some early CD-players have a dedicated Subcode output jack, devices for this are about as rare as the ITTS box. I pick one player with this jack up and after I’m finished with my ITTS emulator I will create ITTS-CDs.

1 Like

As I understand, CD-Text is stored in the lead-in and in some subcode channels. But that’s an implementation detail.

ISO-60958 also defines how ITTS should be reproduced in the SPDIF output of a DCC recorder. But of course it doesn’t go into the actual format of ITTS, beyond saying (I think) that every block of information is 48 bytes.

Obviously, DCC recorders expect ITTS data to be formatted in a certain way so they can display it on their front panels. But for the most part, DCC recorders really don’t care much about the ITTS data on tape. They stream everything to the SPDIF output and interpret what they can (and have to) and ignore the rest.

ISO-61866 is a very big document. But most prerecorded cassettes were encoded with the same software written by Philips, and tested with the ITTS box which also has its limitations (the box that the DCC museum has, only supports a few European fonts for example, no Kanji). So even if someone would have made a DCC recorder with an ITTS decoder, it wouldn’t have mattered.

===Jac

1 Like

I am studying and implementing it.

Then why can’t the ITTS box display 3rd gen text in 1-line mode? I’m not sure if that’s even ITTS. And why don’t the 3rd gen stream it out? I will write my more technical assumptions later.

Do you have any idea where the alleged compatibility originates from? Do you agree with my list or did I interpret something wrong?

Oh you mean the lyrics function? I was wondering what you meant by “3rd generation text”.

I think Philips messed up with the lyrics function. I suspect that

  • The standard was ambiguous and unclear. For example, a tape frame of 64 kilobytes doesn’t fit evenly into 384000 bits so one second of audio is not an exact number of frames.
  • The software that Philips provided to encode lyrics during the mastering process was probably buggy
  • Every recorder has different software to process ITTS, and it’s not unlikely that there were bugs in some recorders that were never solved because engineers didn’t have any sources to test with

3rd generation recorders don’t generate ITTS from the SPDIF output (at least not as far as the DCC museum ITTS box can detect). We can only speculate why:

  • Maybe they DO generate the information but they have a bug that causes the data to be misformatted (my SPDIF decoder project was supposed to help determine this, but got buried under other projects)
  • Maybe Philips decided there would never be an ITTS decoder for consumers so they dropped the idea and told the engineers not to bother writing the code to pass the data from the DRP to the DAIO chip
  • Maybe there was a technical problem that made it impossible to pass the information to the DAIO, for example if it took too much time to process the data and messed up something else, such as front panel communication.

We can only speculate about why some things work the way they do. I worked at Philips Hasselt and I know they had good processes in place for doing architecture, code reviews, etc. But somehow the Japanese were much better (and faster) at creating complicated firmware that worked a lot better than what Philips produced. Stupid mistakes like leaving out the possibility of entering an apostrophe when editing a song title would not be something that would have happened at Sony.

1 Like

I took the time and found a free copy of the relevant standard IEC 60908.

There are two types of CD-Text:

  • The commonly used one called MODE = 4 in the Lead-In; it has as I suspected nothing to do with ITTS.
  • The type during playback MODE = 2 is based on ITTS with the addition of one more data packet format with the only advantage compared to MODE = 4 being the avoidance of additional RAM. I found no reference of it ever being used, but I could be wrong. Subcode is difficult to burn and I don’t have any CD-Text hardware players anyway.

If I have nothing else to do at some point, I’ll correct Wikipedia and add an ITTS article.

1 Like