DTS playback with non-DTS hardware

[Bobby Henderson]

That said, they should have used SMPTE timecode on film prints right from the start back in the nineties.

Does standard SMPTE time code allow for the same data contained in DTS time code? DTS had to modify its time code after the first couple or so features to include movie identification in addition to reel and frame numbers. Some theaters forgot to swap out CD-ROM discs and ended up having the audio from Jurassic Park playing over Heart and Souls. The update fixed that problem.

Not that any of it matters. What's done was done nearly 30 years ago. The DTS type time code has been used more than enough since then to qualify as an actual standard to work with.

[Marcel Birgelen]

SMPTE timecode doesn't include any feature information. You could prepend the timecode with some kind of unique ID, in order to match this up with other playback media. I'm not sure how DTS currently accomplishes this, but there probably also is an ID embedded into their code, that repeats ever so often and can be matched with the playback media on CD-ROM or harddrive.

Note: I'm not a lawyer, this is just me thinking aloud.

As far as I can see, the US patent for the DTS timecode, which was filed in 1992, has expired, so there shouldn't be any license fees to use it. There probably are license fees to call it "DTS" or "Datasat Digital Sound", though one could just call it "Timecode Digital Sound" and I think you'd be fine. I can also see patents for the apt-x100 encoder/decoder that look like they've expired - this EU one, and this US one. And there's already software out there that can decode and encode DTS audio files (I've used it to play back DTS discs, and also encode my own for movies where I couldn't get the disk).

In theory you could put any linear timecode in place of the DTS code on the film. As far as I'm aware, the code is printed onto negatives (or positives in the case of the Cinevator) using an LED that's driven by a DTS timecode generator, so replace that with a different timecode generator and you get a different timecode on the film. And the reader will read out the new one no problem, you'd just need to feed that into your own decoder. However as Carsten says, imo it's better to keep using the DTS timecode to keep compatibility with the current hardware, and I can't see a downside to doing this either.

Yeah, the original patents on the DTS timecode have since expired. Any licensing fee due would be to cover the name and possibly the support you're getting from DTS and/or DATASAT at this point in time. But, the primary reason would be to have an open, well documented standard, instead of an informal, leaked one, with some remaining legal caveats...

[Scott Norwood]

Thinking about this further: I still find the 30fps thing to be a really odd decision. Was 24fps timecode not a thing in 1992? Were they thinking that the format would have a future in the television industry or that 30fps film would become popular?

Does standard SMPTE time code allow for the same data contained in DTS time code?

Not sure, but they could use the "user bits" to indicate the release number.

[Marcel Birgelen]

Not sure, but they could use the "user bits" to indicate the release number.

The User Bits are 3 bits, not a lot of room for some useful feature information, but you could spread it out over multiple frames.

[Mark Gulbrandsen]

Thinking about this further: I still find the 30fps thing to be a really odd decision. Was 24fps timecode not a thing in 1992? Were they thinking that the format would have a future in the television industry or that 30fps film would become popular?




Not sure, but they could use the "user bits" to indicate the release number.

24 fps time code was for sure around in the 90's. One of the first movies edited on a computer editing system was The Pelican Brief, (1993). On a big production the editor gets to choose his editing system and I have seen everything from upright Moviolas to computer editing systems. At first, many computer editing systems came with an operator. The stuff was just too complicated for an editor who has cut film all his life to learn to operate in a short time..

[Scott Norwood]

Interesting. I know that there are methods of cutting movies on NTSC videotape (with 30fps timecode), then converting that to Keycode numbers for film conforming. Why would anyone do this (which seems like a world of pain) if true 24P editing existed?

[Tony Bandiera Jr]

.....

Converting that data from DTS time code and making it look like SMPTE or MIDI time code is a potential point of problems. Such a conversion process takes time. Even a few milliseconds can be enough to cause issues with audio sync. That could either mean audio drop outs with the film print or lip sync being thrown off. ....

Since the DTS timecode is always read ahead of the image and has always featured adjustable offset, I don't think that conversion latency would be an issue at all.

Now if that latency shifts constantly due to the amount of processing needed, that might be an issue but since the data is so simple, again I don't see how it could cause a problem.

If we were trying to convert the digital audio stream from DTS to another, yeah I can see issues there.

[Mark Gulbrandsen]

Interesting. I know that there are methods of cutting movies on NTSC videotape (with 30fps timecode), then converting that to Keycode numbers for film conforming. Why would anyone do this (which seems like a world of pain) if true 24P editing existed?

Scott, all editing on.film productions was done on 24 fps equipment. Most big editing swstems could do 24, or 30 fps. But it utilized data on.hard drives, not tape.

[Marcel Birgelen]

Since the DTS timecode is always read ahead of the image and has always featured adjustable offset, I don't think that conversion latency would be an issue at all.

Now if that latency shifts constantly due to the amount of processing needed, that might be an issue but since the data is so simple, again I don't see how it could cause a problem.

If we were trying to convert the digital audio stream from DTS to another, yeah I can see issues there.

The orignal DTS decoders only had an Intel 486 CPU to handle the decoding, compare that to modern CPUs and there is really no comparison, especially if you're going to use dedicated DSPs, ASICs or FPGAs. Stuff that was pretty much out of reach 30 years ago. Nowadays, even transcoding from one digital format to the other shouldn't be a problem with modern standard hardware. Atmos is mapping beds and audio objects to an "arbitrary" number of channels and doing it quasi-real-time with hardware almost a decade old.

[David Ferguson]

Does standard SMPTE time code allow for the same data contained in DTS time code?

Nearly? DTS timecode has two data frames in it, the first being a serial frame which reports the serial ID of the feature and the reel number, and the second being timecode frames which have the time frame number. SMPTE doesn't have a concept of "reels", just the time, so what the DTS Timecode Generator did was use the hour number as the reel number, so 02:14:32.10 corresponds to reel 2, 14 minutes, 32 seconds, frame 10. This is quite effective because reels obviously can't be longer than an hour.

DTS had to modify its time code after the first couple or so features to include movie identification in addition to reel and frame numbers.

I believe that originally, the timecode on the film only had a few serial frames at the start of the reel. This meant that you couldn't start mid-way through a reel, or if the DTS unit was power cycled, it would have no idea what feature or reel it was playing. The update put a serial frame as every 16th frame, so you can start anywhere in a reel and within less than a second, the player will know the feature and reel.

Yeah, the original patents on the DTS timecode have since expired. Any licensing fee due would be to cover the name and possibly the support you're getting from DTS and/or DATASAT at this point in time. But, the primary reason would be to have an open, well documented standard, instead of an informal, leaked one, with some remaining legal caveats...

The timecode spec is so simple that it would only take a couple of pages to create a well documented version of it. At some point I'll expand my overview of it, as I have a pretty good idea of how it all works now.

Thinking about this further: I still find the 30fps thing to be a really odd decision. Was 24fps timecode not a thing in 1992? Were they thinking that the format would have a future in the television industry or that 30fps film would become popular?

It's not really that odd a decision, as the audio framing and picture framing is entirely separate. You could have the audio running at 1fps, and it would still work fine. I guess 24fps would have been nice for this, but I suspect 30fps was used because that had been used in the past. The encoding, apt-x100, was initially developed and used for HQ audio over IDSN lines, not for digital cinema. If they used 30fps there and it worked, maybe they just used it again.

Since the DTS timecode is always read ahead of the image and has always featured adjustable offset, I don't think that conversion latency would be an issue at all.

Now if that latency shifts constantly due to the amount of processing needed, that might be an issue but since the data is so simple, again I don't see how it could cause a problem.

The timecode is so simple and "slow", there should be absolutely no issue converting it in real time. At least I've never run into any issues doing it. Each DTS frame is 24 bits long, so we're talking 720bps. That's half the speed of an early 80s modem - no issue at all for doing real time conversion on, even by the slowest microcontroller of today's standards.

[Bobby Henderson]

Since the DTS timecode is always read ahead of the image and has always featured adjustable offset, I don't think that conversion latency would be an issue at all. Now if that latency shifts constantly due to the amount of processing needed, that might be an issue but since the data is so simple, again I don't see how it could cause a problem.

One reason I had concerns is possible hardware issues. The theatrical DTS format had a reputation of being significantly more reliable at playback than any of the sound-on-film formats. The time code could be high speed printed more easily than the data spots of SR•D or SDDS and it could "free wheel" over as much as 48 frames of damaged or missing time code before failing out to the analog track. The Dolby Digital format on 35mm improved over the years with better readers and processors, but I witnessed it being flaky from time to time during its early years. Nevertheless theatrical DTS was not completely glitch-free. Any issues with the time code readers, the CD-R drives, etc could result in drop-outs.

A real time conversion of DTS time code to some other time code format might be technologically very easy to do. But what if things aren't working at 100%? That conversion step is an added potential point of failure. If the DTS patents are expired I don't know why it would be such a problem to allow d-cinema processors to be able to understand the DTS time code natively.

If we were trying to convert the digital audio stream from DTS to another, yeah I can see issues there.

Real time audio conversion of a theatrical DTS track to another digital audio format could be tricky. A better question would be why even bother? It's lossy compressed audio, even it is compressed at a fairly mild compression ratio. There could be some legit purposes for converting theatrical DTS audio to other audio formats, like if the original audio master of a movie got lost. For me, the thing I'd like to see is a 35mm or 70mm film print with DTS audio synced up to high quality lossless or uncompressed audio tracks. For archive 35mm (or 70mm) prints it could be an uncompressed LPCM master. For newer movies the film print could be synced with a next-gen audio format.

It's not really that odd a decision, as the audio framing and picture framing is entirely separate. You could have the audio running at 1fps, and it would still work fine. I guess 24fps would have been nice for this, but I suspect 30fps was used because that had been used in the past.

Yeah, it shouldn't make a difference is one second is divided by 24 frames, 30 frames or hundredths of a second just as long as the overall clock of the audio matches that of the image. While audio is mixed, edited and played back along a time line we hear audio in the frequency domain. You can have multiple edits and adjustments happening to an audio track inside just one frame of film or video.

[Elia Orselli]

If the DTS patents are expired I don't know why it would be such a problem to allow d-cinema processors to be able to understand the DTS time code natively.

For the same reason Dolby is not releasing a multichannel analog input board for CP950 Unfortunately, this is not an economically relevant market segment to justify the investment.

I believe that the only possible funder, at the moment, for this type of preservation work would be FIAF (which should similarly pose the problem for Dolby Digital).

[Marcel Birgelen]

Another problem still are the legal implications, because it's often a real hornets nest. Even if the original patents have expired, there may be more recent patents that cover some stupid little addition that may be required to keep the system working. That's the reason why, up until this very day, everybody implementing an up-to-date CD player needs to pay for certain patents to Philips. While the original patents have long since expired, the CD standard has been updated over the years and so has the media.

Keep in mind that DTS, by this time, is nothing more than a pure licensing-operation, so I'm pretty sure they'll try to find a way to get money from you if you use "their" technology. Even mentioning that your implementation is "backwards compatible" with theirs may get you in trouble, because you're using their trademark. So, how do you market a functionality, if you cannot call it by its generally accepted name? Maybe you don't want to expose yourself to those potential legal challenges?

It's that why I still think something like an open SMPTE-based timecode track on film may not be such a bad idea in general. Like Carsten somewhat indicated, there isn't a good reason why it hasn't been on there for the last 30 or so years.

[Carsten Kurz]

DTS is no longer the rights holder for DTS theatrical sound. It was all transferred to Datasat, and then went on to Inventure Studios, who are now responsible for the few DTS film sound mastering jobs that remain. They also do ATMOS mastering, so they may be interested to discuss synced 70mm-ATMOS. Just wondering wether Dolby could have something in their ATMOS licensing that would prevent this. However, there is now IAB which should not be restricted by such licensing.

[Bobby Henderson]

Yeah the DTS company that exists today is mostly a consumer audio entity. I can't really tell if the DTS-X format has been getting anywhere in the professional cinema market. It seems very few movies have been using the format and very few cinemas have been installing it. Dolby Atmos isn't all that widespread either and of those theaters that do offer it not many have Atmos well implemented. On the other hand, Atmos is supported on far more titles. Years ago the DTS-HD format was so common with movies on Blu-ray disc it was practically the de facto standard. In the last couple or so years Dolby has really taken over Blu-ray and UHD Blu-ray with audio in Atmos and Dolby TrueHD. It's getting rare to find any new movie disc releases with DTS audio.

The APT-X100 based theatrical DTS format is very different from the home DTS format used on movie discs, music CDs, etc. The DTS-X format has no relation to the original APT-X100 process either. The DTS company that exists now may not have any attachment to that original DTS format.