I am interested in a solution for S/PDIF input without SCMS detection to USB. The Cmedia CM6610A does support S/PDIF input to USB:
Supports S/PDIF input for 44.1K/48K/96K/192KHz@16/24bit
(96K/192KHz/24bit are available only in USB Audio Class 2.0/High-speed mode)
But sadly, I found no board utilizing that feature, I am thinking about designing a PCB for that chip or modding one existing board. But if I bother to design something, I could just build something completely new, that could support ITTS. Is the ITTS information kept when converting S/PDIF to I2S or would I have to build a custom S/PDIF decoder? Any insight where ITTS data is stored in the signal @Jac?
I found one relatively cheap commercial USB audio interface, that supports S/PDIF in, but it is according to the driver name based on the older Cmedia CM6206, which advertizes SCMS compliance and has lower resulotion. I will keep you up to date, when I receive the unit. B07DGR9M6M is the ASIN, avaible on European Amazon for about 15 €.
The CM6610A seems like an interesting chip. I didn’t read the entire datasheet but it looks like there’s no mention anywhere of SCMS, so I wouldn’t be surprised if it will just decode the audio from SPDIF to USB and disregards the SCMS information completely. I can’t be sure though.
I think you may (also) want to look at the Teensy, particularly the Teensy 3.5 which I will be using for the DCC-i project, because it’s 5V tolerant. It can be programmed in the same way as an Arduino but it’s much more powerful. There is an Audio library available which makes it really easy to create audio projects. For example it should be relatively easy (a matter of drag-and-drop) to create a software project to read the audio from the I2S input, and let a Teensy stream it to a PC via USB. All you would need in theory) is an SPDIF receiver that outputs I2S to the I2S input on the Teensy. And you can use the other I2S port on the Teensy to stream the audio out again, e.g. to an SPDIF encoder. The outgoing audio wouldn’t have any SCMS restrictions; you’re the boss
I think you mean: Is the ITTS information available in the I2S stream that comes out of an SPDIF receiver? The answer is no. The ITTS information is transmitted in the User Data subchannel of the SPDIF signal, and it’s not part of the audio, so it doesn’t end up in the I2S stream. My SPDIF receiver project has some information on how the subchannels are encoded.
As you may know, I did some reverse-engineering on the ITTS box of the DCC museum. The page of that project also has a link to the datasheet of the Mitsubishi M51581 SPDIF receiver chip (whic, by the way, was also used in some recorders). I don’t know if that chip is still available but I imagine that other SPDIF receivers work in a similar way: They convert the incoming audio to I2S and have separate serial output pins with only the bit stream for the User Data subchannel and the Channel Status subchannel. The ITTS box that the museum has, uses one microcontroller to decode the User Data channel and one microcontroller with a Teletext video generator to put the information on the screen.
It shouldn’t be too hard to design a circuit with an SPDIF receiver like the M51581, that has separate pins for the subchannel data, and a microcontroller that reads that data and sends it to a PC via serial or USB. Then you can write a program on the PC that implements the ISO/IEC 61866 standard for ITTS. As you may already know, it’s very expensive to buy a copy of the standard, and the standard is very complicated. There’s no doubt that the producers of DCC cassettes didn’t use the entire standard as it exists now. The Teletext generator in the ITTS box of the museum can only do European characters, for example. But even if you would want to write a program that only implements enough of the standard to work with DCC, it’s going to take a while.
Thank you for your great tips, I will take a look at it later. I bought a copy of IEC 61866 from a Russian seller for 1050 RUB, converted to 14.84 € and received it instantaneously. Long and complicated standard, but at least we have some documentation to work with. I opened your DAI dump and it seems to mostly contain a demo mode, take a look for yourself with a text editor. This means, that the undocumented part of S/PDIF → ITTS should not be insanely complicated. I will try to write a decoder for the demo according to the standard.
I paid $270 for the standard but it should not be too hard to find it cheaper or free.
I’ve looked at the ROM dumps with a hex dump program too. It has some interesting strings including (if I remember correctly) the name of the software engineer who wrote it. Yes it has a demo mode which is activated by a switch on the back.
I don’t think I’ll be making a replica of the ITTS decoder of the DCC museum. It should be easy to reverse-engineer it further with a multimeter to trace some things out, but it’s not really necessary: I can guess pretty much all of the circuitry. With current technology, it just doesn’t make sense to make something like the ITTS box the same way. In the 21st century it should be much easier to accomplish the same thing with less hardware and more flexibility.
I couldn’t find it for free but under USD 17 is good enough. The Mitsubishi M51581 seems to be present in all ITTS compatible 1st/2nd gen DCC recorders. The Philips TDA1315 in the 3rd gen players should support it as well, but it is stored in buffers to be accessed via registers, not streamed out. Same story as in many more modern S/PDIF receivers.
I fully agree that we shouldnt replicate it. But googling I found an interesting application note by ST Micro from 2018. The STM32F4/F7/H7 ARM microcontrollers are able to transmit receive S/PDIF including user data and have lots of IO options like USB, Ethernet, Micro SD, Multitouch Touchscreen and HDMI. A great value dev kit is avaible for under USD 90, what are your thoughts on it for a first look on the specifications? Model number: STM32F769I-DISCO
I’m from the analog era, so I really haven’t got much affinity with digital technology.
But learning everyday I got the idea to record (and backup) the digital information from my DCC tapes to my PC, primarily meant for playing my DCC albums at my desktop computer.
I searched for simple spdif and coax converters to USB but got nowhere. They all tend to transform from digital to analog before entering the pc. And I just want that digital stream to save it in the highest quality possible…
As stated above, I’m really a novice in this area, and in need for some guidance to understand this matter for it’s all mind-boggling for me. I’ve read about sampling but I need the digital stream first. But then again if I have a digital stream, who needs sampling if I could use that same stream to save it in any format that can be listened to. And the same quality as it was in DCC format without compromising.
What should I do to get the digital stream on my pc and save or convert it to FLAC, of course without the step to convert to analog audio and back.
Is there a digital input available for pc that I can buy and capture the digital stream from and convert it to a file format to listen to?
Many thanks for helping me on my way, any help greatly appreciated!
I asked myself the exact question a year ago, so I merge the threads because it is a follow-up on my previous posts; I hope you are okay with this.
I am working on the perfect solution to get the mp1 out, but it will take its time and be complicated. Even just S/PDIF → USB is such a niche product that I found this thread googling the details in the 4th spot.
A few ICs support it, but prebuilt hardware that utilizes it is even rarer. I was close to designing a custom PCB for a TI IC.
By far, the cheapest prebuilt option is some generic Cmedia CM6206 based device, which you can find for less than 10€ with optical S/PDIF in. It works on my DCC730 with a cheap 2-way optical <> coaxial converter, so SCMS seems to be no problem despite the datasheet of the IC claiming otherwise; apparently, there is a pin for an SCMS indicator LED.
Under Windows 10, the default drivers are not enough. I don’t trust drivers from the included CD, so I used some from cmedia.com.tw for the sister IC CM6206LX. Cmedia, the IC manufacturer, is trustworthy, in my opinion. Under modern GNU/Linux, it works out of the box as I read about Mac OS.
The audio quality is as good as you can expect from a digital PCM recording.
However, getting bit-perfect results on desktop is hard with volume-control and other OS-features inbetween.
If you have 329€ spare, you can get yourself a Tascam DR-100MKIII PCM recorder that can record S/PDIF inputs and, of course, everything else you can expect (high-quality internal and external MIC, line-level analog audio unbalanced and balanced as well as AES/EBU digital audio) straight to an SD-card.
By the way, I listened back and forth comparing highest quality Spotify of the exact same recording with DCC S/PDIF in using decent but not high end headphones and could not tell any difference, it sounded the same.
@Henrie I would appreciate to hear back from you on your choice and how it works out.
Thanks very much for your info. I can’t fully understand what’s being said in the article, but you confirmed the need for an S/PDIF input for the part of digital recording.
I immediately began searching for your suggested hardware, and found a CM6206 based device for under $15. After it gets here (within a couple of weeks), I’ll let you know how it worked out.
I bought I think the exactly same thing 2 years ago, for exactly the same reason: to record digitally to PC.
When it arrived, it did not work. Struggled with it for while, then ultimately got my money back.
I did not have windows at that time. I got Linux, but got pure corruption. Then I lent it to a friend with WIndows, and he got the same. Guess it is really broken. Maybe he did not try the special driver.
I got windows now, on my worklaptop, so I could try again…
I’ve been thinking a lot about how we’re going to dump tapes in the future.
I’ve had a Big Plan™ in my head about how to grab the PASC data simulteanously with the SYSINFO/AUXINFO but I keep not being able to find time to get it done.
But I just had a thought: It’s probably difficult to get all that information at the same time and synchronize it and put it into a file on an SD card or on the USB bus or whatever, but it’s probably not hard at all to simply get the PASC data from the I2S subband bus and forward it through a high speed serial port. After all, a cheap FTDI chip can transport up to 3 megabits per second over USB, and PASC is only 384kbps.
In fact, I already have a setup that can do that with a DCC175 (my Turkey Lab). I’m going to think about this for a little while…
Hi Max,
Thanks for the tip, I did not make this modification (yet). I need a Toslink in/output part to do this mod. Maybe it is present in one of my donor receivers, or in my donor DCC players.
Meanwhile I got myself a second hand Tascam DR-100 MKIII
It has a TS/TRS jack 3.5 mm plug for digital input, but I could not find a high frequency (400kHz?) RCA to jack cable yet. I might make one myself and let you know how it works out.
It wasn’t cheap as it was only and rarely used as a backup for a singer/songwriter. He had two of the same Tascam’s .
I paid $175 for the package including power adapter and some special cables for connecting. As I’m a reporter for a regional news magazine myself, I will use it for my assignments too. The Tascam’s quality in recoding is far above my expectations. Especially compared to my previous recorder.
.