How about adding an encoder :)

[merbanan]

git clone https://gitorious.org/dtsenc/dtsenc.git

This encoder could use some love.

[foo86]

An encoder is currently out of scope of this project, which focuses on decoding. Maybe someday...

[MarcusJohnson91]

I know it's off topic, but what happened to XLLDec?

[foo86]

I know it's off topic, but what happened to XLLDec?

It has been evolved into this project and removed to avoid any possible confusion. Just use dcadec, it's already superior in many ways.

[MarcusJohnson91]

@merbanan Does dtsenc support anything but baseline DTS? and it looks like the project is dead...

[merbanan]

It supports dts core and has not been developed much for a few years.

[filler56789]

Yes, it's very improbable that someone will manage to convince Alexandr Patrakov to update dcaenc.
MAYBE Alexei Andropov, the author of the improvements to dcaenc, could be convinced to accept the task. The guy who hosted the original ffdcaenc code at GitHub should know where is Alexei Andropov (or at least I hope so):
http://forum.doom9.org/member.php?u=182798

[ghost]

Why would you want an encoder anyway? DTS is a terrible format. We're all glad here that this projects exists and can turn it into simple PCM.

[MarcusJohnson91]

@wm4 Right? DTS truly is a terrible format, if anything I'd prefer a TrueHD encoder.

[haasn]

The only situation I can think of that would require a DTS encoder is if you're producing your own Blu-rays. And I think if you're producing your own blu-rays, you're probably using different software to do so.

[MarcusJohnson91]

It would be slightly difficult to write an encoder for TrueHD, but a decoder for that has already been reverse engineered, so 90% of our work is already done.

[merbanan]

There is a MLP/TrueHD encoder already. Not complete though. https://github.com/ramiropolla/mlpenc

[filler56789]

The TrueHD encoder is for Macs only. Also, it is much slower than the Master Audio Suite, and in the beginning, it had problems with seamless branching.

[MarcusJohnson91]

@filler56789 Uh, I was using Dolby Media Encoder SE earlier today, and frankly the DTS Master Audio encoder is way slower, not that the TrueHD encoder is a speed demon or anything.

Seriously, it took the DTS encoder like 45 minutes to encode, and the Dolby one like 30.

IDK about seamless branching, I haven't exercised that part of the encoder yet.

[Nevcairiel]

The answer is the usual marketing reasons. Technical merits rarely decide things in such areas.

[MarcusJohnson91]

@merbanan Yeah, I know about that one.

Actually I was working on importing it into FFmpeg earlier today, and it's giving me issues about DSPUtil.h, I asked Ramiro earlier about it, but he didn't know beyond it's been deprecated and split into various, unnamed headers; and the APIChanges file doesn't say a word about it.

[MarcusJohnson91]

@Kit90 IDK about that, frankly I find reverse engineering easier than reading the majority of white papers, especially ones as bad as the DTS-HD one. that one needs fucking Jesus.

[MarcusJohnson91]

I thought those terms were interchangeable?

I meant the "Technical Specification" called "DTS Coherent Acoustics; Core and Extensions with Additional Profiles" version 1.4.1

Also called ETSI 102 114.

[filler56789]

@bumblebritches57: My bad, I should have written «WAS much slower» instead of "is much slower".
By the way... in my opinion, it would be better to have a Pure Lossless DTS encoder, because in general, pure-lossless DTS compresses as good as FLAC, plus it has well-defined rules for multichannel audio, whereas FLAC has always been a mess in this regard =)

[MarcusJohnson91]

@Kit90 I can't speak for anyone else, but when I said "DTS is truly a terrible format" I was talking about how convoluted and complicated it is, compared to other codecs.

with it's frequency bands, core + diff architecture, the fact that some frames may not be lossless, while it still passes CRC checks, etc.

EDIT: DTS-HD MA +Core is NOT smaller than FLAC, OR TrueHD...

unless that was a typo?

[tdaede]

Having an open-source DTS encoder doesn't solve the problem that the format is heavily patented, which is enforced - see takedowns on the Play Store, OUYA store, etc. I'm happy that there's a decoder to get content out of the format, but I don't think the world needs more DTS files.

If you're concerned about the well-definedness of FLAC, I think efforts would be better spent in the CELLAR working group, which is standardizing FLAC (as well as mkv and ffv1). Unlike many standards bodies, there's no "membership" and you can participate just by joining the mailing list: https://www.ietf.org/mailman/listinfo/cellar

[MarcusJohnson91]

@Kit90 I see what you're saying now, I personally wouldn't measure it that way, because TrueHD is a standalone codec and can be reencoded down to a lossy codec such as AC3, but I get it.

[haasn]

The real question for that comparison is why, when designing a new format, would any sane human being ever decide to encode both lossy and lossless audio in the same disc?

Either you need it to be lossless (for reprocessing, archival or audiofoolery), in which case you use lossless audio. Or you don't, in which case you use lossy audio.

What kind of world needs both to be around on the same disc?

[Nevcairiel]

Backwards compatibility is a big concept in our world. Forcing users to buy new hardware all the time limits adoption quite strongly.

[haasn]

^ So when designing a new format, if you know you're going to eventually bolt on lossless placebo modes for marketing reasons, why not just start out with the format being lossless to begin with so that players of the format don't have to change in the future?

DTS is clearly a relic from a past due to bad decisions in the past, that doesn't mean we have any reason to adopt it in the future ever again.

[Thunderbolt8]

considering that DTS:X and Atmos extensions can only work in their native container I dont see how it would make sense to push for FLAC as new standard. well, maybe still for the "normal" streams, but not in case of these new audio formats. (also normal DTS-HD MA has several options for 7.1 speaker placement, I dont know if they are actually all covered by FLAC).

[ghost]

Having an open-source DTS encoder doesn't solve the problem that the format is heavily patented, which is enforced - see takedowns on the Play Store, OUYA store, etc. I'm happy that there's a decoder to get content out of the format, but I don't think the world needs more DTS files.

So why is everyone ignoring this simple fact? Basically, the dts company will harass anyone trying to use it. It's crazy to use this format voluntarily.

[ghost]

So I guess we should discuss whether object based audio is a marketing gag, and if not, then if there's really a reason why free codecs couldn't handle it provided someone defines an extension.

Also, I question that there are really many people who have to encode 3D audio, other than Hollywood, who is in bed with these patent trolls anyway.

[Thunderbolt8]

it makes more sense to discuss this when someone finally provides the definition of the extensions. otherwise there is no point thinking about it.

[Thunderbolt8]

a bit off topic, but considering the last change was a month ago now: Is "everything" fixed now/working as intended?

[MarcusJohnson91]

@Thunderbolt8 What do you mean by that?

DCADec itself isn't done, I've still got to finish the LBR decoder, and we still need to add in support for dialog normalization and dynamic range compression, and a few other features.

Then of course there's DCA's next gen codec extension which hasn't been published yet.

[Thunderbolt8]

by support for dialog normalization and dynamic range compression you mean the ability to apply such things? or also remove them?

[MarcusJohnson91]

Like applying it to the decoded audio.