Software for the DCC175 Portable

I don’t know if Windows Me works with DCC-Studio (I never tried) but XP doesn’t work with DCC Studio.

I used DCCU both on my Windows 98 machine and my Windows 10 (x64) machine. On my Windows machine, DCCU worked fine but there was a problem on Ralf’s Windows 98 machine. I recompiled the latest version with Visual Studio 6 to fix that. Make sure you use short file names (8 characters or less) with DCCU; I’ll add some code to improve this (i.e. truncate file names), in the next few days.

To test DCCU I mostly used files that I made from tape with DCC-Studio, and MP1 files that I generated with mp2enc which is part of mjpegtools. Tip: mp2enc doesn’t deal well with id3 information in WAV files so I converted my WAV files to RAW before encoding them with mp2enc.

Exact Audio Copy should do an excellent job of grabbing CD’s. The problems you had are probably related to access rights. Try creating a directory under your personal profile directory and save the files there. The root directory of the C: drive is read-only in Windows XP and later if I’m not mistaken, so if you want to put your files there, you’re going to have to change access rights on the directory where you’re storing them. Or you can run EAC as administrator I guess…

=== Jac


I’m happy to report that Windows ME is working flawlessly on the Dell D610 with DCCStudio and the 175. 5 tapes written so far with no issues. I chose this OS as a test because it is about a million and one times easier to install because it has USB flash drive support built-in. I only needed to install a few drivers to get it fully working. Super easy to grab the needed drivers on my Mac and then install them on the Dell using a USB stick. PASC encoding was far too slow on the Dell machine and took several hours to encode one CD. So, I just installed Windows XP in a VirtualBox VM on my Macbook Pro and did the CD Ripping and Encoding there. Now it takes under a minute to rip each track and then about 1.5 minutes to encode the track in PASC. With this success, I’m very excited to start using DCCU tomorrow and start recording a huge collection of 96/24 Hi-Res audio.


That’s great information. Thanks!

The mp2enc encoder could save you a lot of time. It works from the command line unlike dcc2wav, but it’s much faster: a 6 minute audio file takes about 18 seconds to encode to MP1 on my 2018 Windows machine (2.9GHz processor).

I’m working on some improvements to the mp2enc encoder that you will find interesting. I have some high-priority yard work and actual work to do first, but I expect to release something this weekend. Stay tuned!

=== Jac


Would it be possible to reverse engineer the software suite and then recompile it with a 32/64 bit compiler? Then we couIld use it in windows 10. I am currently looking into Ghidra ( , which helps with reverse engineering software. Out of curiosity, I loaded STUDIO.EXE in it and looked what it came up with. I do write java-code incidentally and some c-code for arduino projects, but writing c-code is not my hobby nor my job, and I am also lacking knowledge about DCC architecture.

1 Like

C decompiling is very hard and 100% accurate even harder, putting the work into a fresh implemenation of a DCC software interface for 2nd or 3rd gen is imo the way to go. The software is also using weird Windows 9X (DOS-based) system calls, which are incompatible with anything modern, if it would just be compiled to 16bit, it would work fine on Windows XP.

And in terms of further reverse engineering, I would like to go with the DCC175 side of the DCC Link as there are way more DCC175 available than DCC Link and it would be more compatible with other mods.

I agree, but there are perhaps some DCC-specific functions in the old software that you can reuse in a new implementation. If you combine that with modern GUI based on current applications as Apple I-tunes and USB support, you would have something really great.

Still this would be not scalable, not sellable at a profit and would take lots of time. That makes it difficult to realise.

The magic is the chip and we have better documentation of the inner workings of DCC than of the PC side of that. If you want you can capture the parallel side of things and build a software that can archieve that using modern standard APIs for that. I would be happy to assist you.

iTunes does not have an API, as Apple wants to sell their products it will be specialisized with maybe adding text, possibly ITTS and more but will definetely be nicer to use and run on a modern system.

I am not familiar with the interface on the DCC175 side, @Jac is it rather close to the raw tape frames or I2S and sys/aux or another new abstraction layer? I would be good to keep as much work as possible compatible between multiple devices.

If it is an improvement for you you could also use an expansion card (ie. PCI or PCIe) with parallel compatible to Windows 9X and pass the whole card to a Windows 9X VM. Could also be a laptop with ExpressCard or Thunderbolt if you have that equipment and the BIOS/EFI supports the passthrough.

Yes, it’s possible to disassemble the existing software but I feel that it would be a big waste of time. Disassembling DCC-Studio and reassembling or recompiling to a 32 bit executable file won’t be enough to make it work. The program accesses the printer port directly and all current operating systems will prevent a regular program from doing that. Only device drivers should access hardware directly, and writing device drivers is difficult, not to mention you have to jump through hoops like getting your driver to be WHQL certified to make it install on Windows. And after you go through all that effort, a 32-bit version of DCC-Studio with a new device driver will only benefit those with a Windows computer and an original cable from Philips.

So the plan is to make new hardware that gets connected to the USB connector of a PC (or Mac or Linux machine). DCC-Studio won’t work so we’ll have to write new software. But there are many things that DCC-Studio can’t do, that can easily be implemented in our own software. For example, DCC Studio shows you a nice information window with all the track titles while you’re copying a tape to hard disk, but it doesn’t use the information to write the audio to separate files with automatically generated file names, or even to generate markers in the single track file. That is an obvious feature that I can easily implement from scratch, without the need to decompile DCC-Studio first.

I disagree with that. C is such a low level language that decompiling is usually pretty easy. I did it with the Lode Runner game for DOS. That took a long time, though!

The hard part is when the optimizer does a bunch of weird things like reordering and reusing instructions. However in the 1990s, optimizers weren’t that good yet. Based on my experience, it should be pretty easy to disassemble and maybe even decompile DCC-Studio but as I said, it won’t get you anywhere, other than understanding how the program works.

If you want to know how the plug works, it’s probably much easier to disassemble the DCC.SYS device driver that the DOS Backup program installs. That driver focuses only on sending data back and forth and controlling the recorder, and another guy and I worked on disassembling it in the 1990s. We abandoned the project because we didn’t know enough about DCC at the time, but I may get back to it because it may help me understand the protocol on the serial port.

The interface has a half-duplex version of the I2S sub-band bus, i.e. the PASC data, and a synchronous serial port. The bit clock isn’t on the cable, probably because it would generate too much interference and wouldn’t arrive unscathed anyway, but it can be easily derived with a PLL and the word clock. Extracting and injecting PASC/MP1 data should be extremely simple with a microcontroller with an I2S interface such as the Raspberry Pi or the Teensy. I’ll probably use the Teensy 3.5 because it’s 5V tolerant, has I2S, a MicroSD card reader, SPI buses and USB, and there is an extensive audio library framework that looks like it’s possible to make it appear to the USB host (PC, Mac or Linux) as a USB audio device. If it’s possible to make the Teensy appear as a multi-point USB device, I’ll also make an HID device appear for control of the recorder.

The synchronous serial port has a protocol that I tried to analyze, but haven’t been successful yet. In fact I sort of abandoned that effort because there were just too many unknowns. I know that the recorder and the plug exchange data continuously in packets of 32 bytes, and it appears that packets are handled in groups of three packets (96 bytes) but I’m not sure of that yet. I’ve only looked at a continuous hex dump of the serial data stream from the recorder to the plug, and it looks like it has the SYSINFO and AUXINFO data from the tape during playback. If we’re lucky, it’s also possible to record SYSINFO and AUXINFO through the serial interface, and make our own prerecorded cassettes. From the datasheets, it looks like the chipset can do it (I’m not 100% sure) so if the microcontroller simply transfers data to the L3 bus, the serial port can do it too. I don’t know yet.

I don’t think that will work. I tried using a VM with Windows 95 connected to a physical parallel port sometime around 2003 so things may have changed since then, but you have to keep in mind that even VM software like VirtualBox also has to follow the rules and talk to hardware through device drivers that are installed in the host OS. And the DCC-Link works different from a printer, so chances are that it still won’t work, although I haven’t tried recently, because I don’t have any PC’s with parallel ports anymore anyway.


Comparing to Java, .NET and other languages that can be decompiled virtually perfect it is hard, of course doable but I doubt it is worth the effort.

After getting the new 175, I took a trip down the rabbit hole and re-recorded all of my mix tapes (48) with proper titles, artists and track info. At long last I am ready to begin converting a bunch of Hi-Res Audio files. I got mjpegtools tools installed and converted a test file from wav to mp1 using this set of parameters: mp2enc -v 1 -b 384 -l 1 -r 48000 -o ‘/Users/macos/Desktop/DianaRoss/03TheBoss.mp1’ < /Users/macos/Desktop/DianaRoss/03TheBoss.wav
Does that look correct? Am I missing any required parameters? I don’t want to feed the wrong source file to DCCU. Any other tips?
Thanks, David

The -r parameter isn’t necessary unless you want to change the sample rate of the WAV file. If the WAV file is already 32, 44.1 or 48kHz, I would leave the sample rate what it is. Sample rate conversion to a higher sample rate will not improve the audio.

Edit: you will also want to use a short file name (DOS 8.3 filenames) for output, otherwise the current version of DCCU will use file names that dcc-studio won’t be able to work with.
So use for example -o ‘03boss.mp1’.

Other than that, there’s no problem with that command line except you need to be aware that the WAV file parser in mp2enc is not very good and will basically regard all data as audio samples. If you use software that adds information such as title, artist name etc. to the WAV, that will translate to loud noise at the beginning of end of the MP1 file. (EDIT: This problem was fixed).

I had the best results converting wav files to raw first (to make sure all meta information was gone) and then feeding the raw file to mp2enc using the -R rate,chans,bits parameter to specify the raw data encoding.

Eventually, I’ll integrate a better WAV file parser such as libsndfile, but I’m extremely busy with work right now so I won’t have time for DCC for a few weeks. I have some interesting changes to the DCC-SE and DCCU projects that I’m working on, but they will have to wait. Sorry and thanks for your patience!

=== Jac

1 Like

Thanks for the tip on the tag info in the file causing noise. That is exactly what I encountered. All of my files have artwork ,tag and Replay Gain info embedded in them. The reason that I need to use the -R option is that all the Hi-Res Audio files are at least 24 bit / 96kHz or higher. So, I’m downsampling the audio not upsampling it. As I type this, I just realized that I never specified the bitrate in the converted files. It will need to be downsampled to 18 bit. I will take your advice and perform all of the conversions when I export the files to wav and dispense with the unnecessary parameters in mp2enc. That seems like a more logical route.

I’ll be mindful of the 8.3 names too. For the time being, I’m running mp2enc natively on my Mac but running DCCU and DCC Studio file conversions in a Windows XP Virtual Box VM on the same Mac. Tape writing is being performed on a Dell D600 running Windows ME. So far, I haven’t had any issues with long file names causing issues when being converted to 8.3 names. It might just be peculiar to my setup. But, I will keep an eye on it for conflicts.

Thank you so much for putting the time and effort into this project. I’ll be looking forward to the changes that you will be making.


1 Like

I am working on amazing progress, too. I hope you are doing okay, would love to talk to you about it, hit me up when you have any time to spare at any time.

I performed a super cheap drive upgrade to my DCC 175 laptop. The Dell D600 laptop that I’m using in conjunction with the DCC 175 has an old PATA/IDE interface and the drive was developing issues. While true SSD hard disk replacements are available for IDE they are seem expensive to me. I found a very inexpensive Mustpoint - SD Memory Card to IDE 2.5" 44 Pin Male Adapter Converter on Amazon for US $15. I had a 128GB SD card that I installed in it. Windows ME doesn’t use the SmartDrv like Windows 95/98/98SE does. It uses entries in the system.ini to control the [vcache] settings which perform the same function. As a test, I blanked out this section and wrote several tapes. I did not get any buffer under-run errors because the access times were fast. I realize that SD has a finite write cycle (SanDisk says 100,000 writes typical) but this shouldn’t be much of an issue since most of what this workstation does is read data and write it to tape. I’ll report back after testing this config for a longer period of time.



Finally! I’ve been playing around a bit with mp2enc and the new DCCU. My source WAV originates from a 24-bit 96kHz FLAC file and is therefore a 24-bit 96kHz WAV file as well.


When using:

mp2enc -v 1 -b 384 -p 1 -r -o 01.wav 01.mp1

… I’m getting a somewhat distorted or dampened MP1 file that seems to miss out on large parts of the audio. I listened to it on Foobar and VLC.

And if I’m trying to use DCCU 3.1, it won’t do more than mentioning “0 frames” and seems to hang.


Anything I am missing?


I think you needed the patched encoder by @Jac, I am not sure if it is released yet.

The latest version of MP2ENC is at Releases · DigitalCompactCassette/DCCSE · GitHub
The latest version of DCCU is at Releases · DigitalCompactCassette/DCCU · GitHub

The correct command to encode a PCM WAV file to MP1 is:

mp2enc -l 1 -b 384 -o “outputfilename.mp1” <“inputfilename.wav”

The first option is a lower-case L (for Layer). WIthout it, you get an MP2 file which is not compatible with DCC.

By default it will use 48000 Hz stereo but 44.1kHz or 32kHz are also available as an option.

Don’t forget to use the ‘<’ in front of the input file name. The program gets its input from stdin which makes sense on *nix environments but not in Windows. I will probably make a modified version some day that works differently. I will also eventually integrate the DCCU functionality into it.

The correct command for DCCU is:

DCCU inputfile1 [inputfile2…]

The command line syntax for DCCU is also not very useful and may also change in the future.

DCCU automatically generates an MP1 file if the input file name has an MPP extension, and generates MPP and LVL and TRK files if you the input file name has an MP1 extension. The LVL file is a dummy file; you won’t see the audio levels in DCC-Studio. I’ll fix this in the future.

The reason your DCCU version doesn’t work is probably because you are trying to convert an MP2 file so it can’t find any MP1 frames. You also don’t have the latest version (currently 3.2).



@Jac Thanks a lot! How could i have missed it :man_facepalming:

Very good though to have your detailed explanation now as well, thanks again :grinning:

There’s a lot of information that’s easy to overlook. I wish I had time to rewrite the FAQ page and/or write some introductory articles.



8 posts were split to a new topic: DCC175 Software on Dell Inspiron 8200