Tape length on DCC175 or DCC170 not correct


When using a DCC175 and DCC studio, the tape length you can use never truly measures up to the real tape length. The same thing happens when you are not using the Studio Program, but are recording via line input btw.

For example if you use a 90 minute recordable tape on a DCC951, chances are that you will be able to record about 46 minutes, as the tapes are usually a bit longer.

On a DCC175 you might be able to get 44 minutes, but always 1-2 minutes short. On side B the same thing, but progressively even worse. Since the A side flips in this example at 44 minutes, you will potentially loose another 1-2 minutes, so your B side would then be around 42 minutes maximum.

Since the portables doe not have any physical switches/sensors for the tape length, like the regular recorders, I have not been able to figure out, how a portable DCC170 or 175 determines what tape is actually inside the recorder. There is nothing on that topic in the Service Manual I can find.

Any help would be appreciated.

It uses the tachometers (optical sensors on the take up reel and supply reel) to figure out the current tape position. And obviously it’s not doing a very good job.

It might be possible to hack something into the DCC175 to generate fewer or more tacho pulses than there actually are, based on the existing tacho pulses, but this would be a bit of a challenge: The signals from the outputs at pins 6 and 8 of IC QR01 would need to be intercepted and processed by a microcontroller. That same microcontroller would send fake tacho signals to the recorder microcontroller and make it think that the tape is longer than it is. A simple 8 pin 3.3V microcontroller would probably be enough: only 2 or 3 input lines (one for the direction, two for the pulses from the real tachos) and 2 output lines are needed.

Such a hack would be easy to implement for someone with enough soldering experience and a stead enough hand to lift the legs of the existing IC QR01 and connect some wires from the new microcontroller to the circuit board. But the software could be a bit of a challenge. I have some idea of how it could be done but I’d have to do some research and I already have a lot of other things on my plate.

For one thing, US5923490A - High speed searching of digital cassette - Google Patents gives some hints about how to determine where you are on a tape based on how fast the reels rotate.

Anyway… I don’t think the recorder performs any complicated math to determine what the tape position is. I speculate that it just has some tables that it uses to guess where it is. And because of problems with mechanical accuracy (or because the firmware engineers were too careful and made safety margins too big), it just runs into problems near the end of the tape, goes into a minor panic and stops the recording.


PS I found out that the positioning determination code in the DCC730/951 is very good. The deck controller continuously communicates the estimated current tape position to the main microcontroller via a 38400bps serial port, and it knows the position with a few seconds of accuracy, in less than 5 seconds after starting to play an analog tape, regardless of how long the tape is and what position the tape is in when you insert it. So it can be done; the DCC175 apparently just doesn’t do as good of a job as the DCC730/951



Interesting case.

First, I think @Jac is right, that mechanism of measuring the rotation speed/timing of the spindels to calculate the position on the tape has been used a lot in the past. I think that that is also how VCRs used to know the remaining time on a blank cassette that is spooled towards the end.

I have a few questions:

  1. Does this happen on every 175, or is this a one-time deviation of that player?
  2. If the tape has been recorded previously, by a recorder that DOES record till the true end of the tape, then there is time data recorded till the end. So the 175 could potentially read that and continue recording maybe.
    2a) What happens when you use a tape that is new or has been bulkerased?
  3. Does the same anomaly happen with C60 and C75 cassettes?
  4. This one is a long shot (and probably very wrong), but I want to mention it anyway: Is the tape running too fast on your DCC175? If you adjust the speed slightly (RU51) so that it takes 46-47 minutes for a side (but keep within the DCC tolerance!), the music might fit.
  5. I might do some testing of my own, I have two DCC175 that work well, and I can test with DCC-Studio as well.


Thanks for your feedback.
Here are my answers.

1 Like

@Jac and I worked on this last night and try to trick the reels like this, but DCC Studio did not like it.

Who knew it performed self-testing :smiley:

1 Like

I think the state of the tachos is sent to the PC as part of the recorder status and DCC-studio doesn’t like when both signals go low and high at the exact same time.

That does make me wonder, Ralf, does the recorder record the entire tape when it’s not used with DCC studio?

If so, that would indicate that DCC studio does its own tape position dead-reckoning, and it’s not a recorder firmware bug. And that would make the problem a non-issue if/when I manage to reverse engineer the cable and connect a microcontroller.

=== Jac

1 Like

As I needed the recorder for other testing, I put the original board back in.
I was not able to make a regular recording, to see if it would accept the full length when not using DCC studio.

Actually I was wondering if an unmodified DCC175 can record a tape all the way up to the end of side A and B without DCC-Studio.

I’m sure I knew this before because I know I took my 175 to my cousin to record his records and CD’s every once in a while when I was still in the Netherlands, but it’s been a long time and I don’t remember. I could test it myself and I will, but it’s put away right now.


In my testing the recording never fully reached the end of the tape on a DCC175.
Even when not using DCC Studio.

So I finally managed to do a test. I recorded a playlist of 54 minutes onto a bulkerased DCC C60 cassette using the analogue input and a DCC175 recorder.

The recording on side A got until 31:24 and then the tape switched sides and resumed immediately on side B in the middle of a song, as expected.

Afterwards I managed to take the tape out at that exact switchoverpoint and measured the length of the remaining tape in the shell, it was 1,40 meter. So with 4,76 cm/s that would be around 30 seconds tape length that was not used.

The playlist was already finished after 54 minutes, but the recording continued of course with silence.
So playing back side B revealed surprisingly that is lasted until 63:30 on the counter, and by that time the leader tape was reached too.


P.S. funny how the DCC175 says 63:10 and the DCC730 1:03:10 for the same point on the tape.

1 Like


Can you try the same thing using DCC Studio?

The problem we are seeing is growing with the tape length. So it is worse on a 90 minute tape.


Hang on, I’ll try that.


update: recording now.

1 Like

Just did the recording on the same cassette, same DCC175, using DCC-Studio.

Side A got to 31:30 when the direction flipped mid song. The remaining tape was approx. 70 cm, so that would be around 15 seconds early.
I would say that qualifies roughly as the same as the previous test.

Side B got to 62:24 this time when it reached the leader tape.

Hope this helps somehow.


Ralf, are you getting similar results? 15 seconds of tape remaining doesn’t seem so bad. One could argue that the recorder is doing its best to protect users from depending on the last few seconds of tape which are the most likely to get stretched or mangled anyway…

If you’re losing minutes and minutes of tape, I can think of a hack that we can try to make the recorder think that it hasn’t reached the end of the tape yet by faking the signals from the tachos. But if it’s only a few seconds as @pvdm says, it might be too much to ask for.


I get about 44 minutes on a 45 minute tap (that is actually 46 minutes in length) using DCC Studio.

The problem is with the pre-recorded master tapes we are using.

@pvdm would you have a pre-recorded tape to sacrifice and test?
First delete all old recordding with the bulk eraser if you can, determine the original length and make a recording.


I am not exactly sure what you want me to do Ralf. Could you elaborate on that?
-‘prerecorded master tapes’, do you mean regular prerecorded tapes?
–Why would you want to record over them?
-If you are referring to regular prerecorded tapes, aren’t these sometimes of a non-standard length, custom made by the cassette-duplicator?
-In that case I would have to determine the length first using the (recorded) timecode, before bulkerasing them, or otherwise the recorders would not know how long the tape exactly is. When a tape is blank (not recorded) my experience is that the recorders are oblivious :smiley: and only do a very rough estimate when winding, if they are doing an estimate at all.

In the meantime I am doing the same test compilation with DCC-Studio with the same cassette, but with my other DCC175, to see if that behaves any differently.

Also I should repeat every test a second time, to see if the results are persistent or if the outcome is different every time.
Problem is that it takes a lot of time :smiley:


The second DCC175 reversed to side B at 29:46, so a lot earlier than the first. Same tape, same compilation.
Side B lasted until 58:33 and then the 175 shutsdown completely on playback. Both 175 do that. So there is some strange marker on the tape there. A DCC730 just stops at that point.


The plot thickens!

While recording, the recorder doesn’t read the tape. There isn’t any sort of “magical marker”. The recorder simply tries to guess how much tape is left, probably judging by the rotation speed of the supply reel.

When you start recording, the chipset reads the tape for a short time so it can switch to recording mode at the beginning of a tape frame. Possibly it also synchronizes with the PASC frames but maybe not – it’s not really necessary because finding the start of a PASC frame is a matter of finding two bytes that are set to FF.

By doing this, the recorder guarantees that the time codes on the tape are continuous, so that a super user tape doesn’t change into a user tape. Once the recorder has switched to record mode, it’s impossible to read the tape. The playback heads are behind the recording heads so if it would be possible to monitor the playback heads during recording (which if I understand correctly, it isn’t) because the playback heads would read the bits that the recording heads just recorded to the tape.

When the recorder stops recording, it doesn’t stop the tape right away. It records a short marker that says what it did at recording time: change sides or end the recording. The “end of recording” marker (that’s not the official name but I can’t think of the real name right now and I don’t feel like digging up the DCC system description) is what the recorder looks for when you use the Append feature.

So there’s no way for the recorder to know whether the tape has reached the end, unless it has an optical sensor (which I think only 2nd gen recorders have!). Even if a recorder has switches to detect how long the tape is supposed to be, there’s still some inaccuracy about the actual capacity. The engineers wouldn’t rely on those switches anyway because that would mean that if any manufacturer would make any kind of special tape with some extra capacity would make it look as if the recorder is broken. That would be bad. So they decided to do away with the tape length switches altogether (saving money) and just let the recorders estimate how much tape is left. And in order to make sure that there is time to record a market at the end of the recording, there must be a bit of a safety margin.

In a controlled environment (like making a recording of a known length on a tape that has a known length) it would be nice to have a workaround and force the recorder to record the whole thing. Maybe it’s possible to make a hack. I wish I had more time.

=== Jac