175.zip (3.9 MB)
Philips DCC175 - DCC2WAV.zip (322.9 KB)
Philips DCC175 - DCC-Backup v3.20A.zip (878.1 KB)
The original software for the DCC 175 by Philips
DCC Studio
DCC 2WAV
DCC Backup
2 Likes
Thank you very much for the software, keep up the great work!
Greets Tom
1 Like
Great, thanks Ralf.
i downloaded them, having a dcc 175 , bought from first owner, i’m happy with this.
greetz, Harrie
1 Like
What’s the last version of Windows that DCC Studio will work with? Windows 98, Windows 98 SE, Windows 2000? Any success using a laptop running one of these versions but using a USB to IEEE 1284/Parallel adapter like this with appropriate drivers. I have lots of old laptops that will run these OS versions but none with parallel ports.
Thanks, David
Windows 98SE is the last version that will work.
So far nobody was successful using a USB converter. Your pc needs a dedicated parallel port.
How about trying an PCMCIA to Parallel adapter? It was pretty common on laptops of this time period.
I’ve never seen a parallel port on a PCMCIA card but also likely won’t work. The DCC studio and DCC backup software won’t find the port unless it’s at one of the dedicated I/O addresses where parallel ports would be. And it accesses the port directly with CPU instructions that are illegal for normal programs under Windows NT (which includes any version of Windows 2000 and newer).
The software MAY be usable under Windows Me (I never tried) but it was tested with Windows 98. If you have to set up an old version of Windows just to use DCC studio or DCC backup, you might as well use a version of Windows that it was tested with.
The DCC2WAV software works on Windows up to XP by the way, because it doesn’t need the connection to the recorder and XP is the last version of Windows that can run 16 bit programs. But it’s really slow. Instead, you can use an MPEG 1 layer 1 encoder/decoder and my DCCU utility to convert MP1 files to MPP for the DCC-studio program and vice versa.
The DCC backup program is pretty useless for any real world applications. It doesn’t recognize long file names so it’s really only useful up to Windows 3.1. And because data is recorded to DCC cassette at 384kbps, it’s very slow compared to other solutions. Also the capacity of about 250 megabytes per tape makes it uninteresting.
And before you ask: you also can’t use Windows 98 in a virtual machine on a real machine where you let the VM emulate the printer port from a real printer port. I admit, I haven’t tried this in a long time (probably 2003) but it didn’t work back then. The DCC studio software uses the printer port directly without a driver, and the emulation would have to cooperate specifically with DCC studio to be able to do this.
=== Jac
1 Like
Jac,
I finally found the time to configure a Dell Latitude D610 (sans WiFi card) to dual boot Windows ME/XP to work with the Philips 175. I’m ready to try to use your DCCU Utility. Are you using a CD Ripper (which one?) on the same workstation that has DCC2WAV or on a newer machine? Exact Audio Copy gave file write errors when saving the .wav file in any directory that I chose.
Thanks, David
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 (UPDATE: This has been fixed) 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
2 Likes
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.
David
2 Likes
That’s great information. Thanks! By the way, Windows 98 SE (Second Edition) also has a mass storage device driver built in.
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
2 Likes
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 (https://ghidra-sre.org/) , 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.
===Jac
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.
Jac,
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