anyone compiled and tried dcaenc ?

[Selur]

https://gitorious.org/dtsenc latest update 17.07.2014
https://gitorious.org/dtsenc/mulders-dtsenc latest update 22.04.2012
-> not sure if LoRd_MuldeR even is aware of the updates

[LoRd_MuldeR]

Originally Posted by SeeMoreDigital

I guess LoRd_MuldeR has compiled it himself for his own LameXP audio encoding application...

I wonder how far it's possible to go with DCAenc. Could say, support for DTS-ES and even DTS 96/24 be added?

I think his question was more related to the latest dcaenc updates from 2014:
https://gitorious.org/dtsenc/dtsenc/commits/

My branch was based on an older version from around 2012 and has not been updated since then:
https://gitorious.org/dtsenc/mulders-dtsenc/commits/

[Selur]

@LoRd_muldeR: any plans on updating your repository?

[LoRd_MuldeR]

Originally Posted by Selur

@LoRd_muldeR: any plans on updating your repository?

From what I can see, all changes after Jan 2012 are either related to the ALSA plug-in or documentation updates.

Not sure how relevant that is. In the Windows version, ALSA is not even compiled in...

[Midzuki]

Originally Posted by SeeMoreDigital

I wonder how far it's possible to go with DCAenc. Could say, support for DTS-ES and even DTS 96/24 be added?

Now that amtm is not a forum member anymore, that possibility is highly-unlikely : –/

Originally Posted by amtm

So I've found the updated ETSI specs for DTS that covers the Xch extensions and forwarded it to the author. He seems to have been working against the old 2002 ETSI spec which did not cover these extensions in detail. If he's unable to spend time working on adding support for Xch, I may get my hands dirty and try to hack the support in myself.

BTW, even changing the bitrate granularity from 4-bytes/frame to 1-byte/frame (so that dcaenc could match the streams created by the payware encoders) is not as trivial as I thought, according to the answer I received from Patrakov some days ago:

Originally Posted by Alexander Patrakov

> Greetings again ^^
>
> Only today I noticed the following, whereas the commercial DCA
encoders can use a bitrate such as 1509.75kbps (AT 48kHz), dcaenc
cannot. Then I realized that this limitation is a result of the "bitrate
step" implemented in dcaenc --- 4 bytes (32 bits) per audio frame. So
the question is, would it be too difficult or problematic to reduce the
"bitrate step" of dcaenc to 1 byte (8 bits) per audio frame?
>
> Best regards.

I am aware of the issue, but have no time to fix it.

It would require refactoring (read: full rewrite) of the bitstream
writer. Actually, the spec talks about writing 32-bit words having a
certain endianness, that's why I implemented it this way. The one-byte
granularity is a non-standard extension. It's a shame that it is
required for DVD in the cases where the muxer cannot pad the stream
itself.