anyone compiled and tried dcaenc ?

[Selur]

Just stumbled over http://aepatrakov.narod.ru/dcaenc/ and was wondering if someone compiled and tried it.

So if anyone has some experience to share please do so. :)

Cu Selur

[Kurtnoise]

same experimental encoder uses in ffmpeg/avconv tools...

[amtm]

No this is a new one as the blog post here (http://patrakov.blogspot.com/2011/09/i-wrote-dts-encoder.html) points out.

The DTS "encoder" in FFmpeg was ported by someone else from my old proof-of-concept code that served as a tool to understand the DTS subband transform. It could only encode stereo PCM files into a valid DTS bitstream of the same bitrate, which is useless for any practical purpose. Now dcaenc provides a useful encoder that accepts multichannel sound and encodes it to the bitrate specified by the command line parameter.

[Midzuki]

OK, since "nobody" :devil: cares... :D

Downloaded the dämn source code, configured, compiled dcaenc.exe and gentables.exe, and...

- CONs:

does not have a progress indicator ;

it's slooow :rolleyes:

-PROs

it works :) ( or at least I think so :p )

Tested sample = an ordinary CDDA track (stereo, 16-bits, 44.1kHz)

Resulting output (@576kbps) = plays fine with Mplayer

:cool: :cool: :cool:

[amtm]

What about playback using something other than mplayer? Do you have the Arcsoft decoder you could test a sample with? I'd try but I'm not at home right now.

[Kurtnoise]

No this is a new one as the blog post here (http://patrakov.blogspot.com/2011/09/i-wrote-dts-encoder.html) points out.

your quote is outdated...it produces multichannel (only 5.0 & 5.1) as well.

[amtm]

Great but still doesn't change that this is a new encoder which is not part of ffmpeg as the author points out.

[amtm]

The key words: The DTS "encoder" in FFmpeg was ported by someone else from my old proof-of-concept code

So even if the encoder in ffmpeg/avconv now has 5.1 or 5.0 support doesn't change the fact that this NEW encoder is not the same one you mentioned as he explicitly points out.

[Kurtnoise]

just compare by yourself instead of writing...

[amtm]

just compare by yourself instead of writing...

I did compare the source which is how I know they aren't the same thing. The current encoder as linked in the blog post is dtsenc (http://gitorious.org/dtsenc/dtsenc/trees/master) which even with a cursory glance is obvious it's not the same encoder as in ffmpeg. It's been significantly modified since ffmpeg integrated and changed his original code from 2008.

[Midzuki]

What about playback using something other than mplayer? Do you have the Arcsoft decoder you could test a sample with? I'd try but I'm not at home right now.

Currently my home PC still is a mess :( which means the DirectShow environment (read: codecs and splitters) has not been optimized yet ( because I'm too lazy, yes :o ). I haven't even re-installed foobar2000 yet :eek:

Still, with or without Mplayer :) the program dcaenc.exe needs to be tested "exhaustively" :devil: This will include samples @32kHz, 5.1@44.1kHz@REAL1411kbps (i.e., without SPDIF-padding), Back-Center channel properly-flagged, etc, whatever :)

[amtm]

That's okay just curious. I still need to give it a good testing. I've only had time to glance around the source so far. If only for 2.0 and 5.1, since I don't believe it yet can do more than 6 channels, it sounds like it could be great for fixing the broken silence frames issue in delaycut.

[Midzuki]

...
...
it could be great for fixing the broken silence frames issue in delaycut.

That's a good point. AVI-Mux GUI might use it as well
( however nobody but Alex Noe himself would want to rewrite and recompile the source-code, apparently :( )

Anyway, more good news: foobar2000 likes dcaenc :p

[LoRd_MuldeR]

@Midzuki:

What build environment did you use to make the Win32 build? MSYS+MinGW?

If so, could you give me some advice on how to properly setup 'autoreconf' under that environment?

It fails for me with:

MuldeR@MULDER-PC /d/SVN/Tools/dtsenc
$ autoreconf -f -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
/bin/m4: unrecognized option `--gnu'
Try `/bin/m4 --help' for more information.
autom4te-2.68: failed to run /bin/m4: Bad file number
aclocal: /usr/bin/autom4te-2.68 failed with exit status: 1
autoreconf: failed to run aclocal: Bad file number

MuldeR@MULDER-PC /d/SVN/Tools/dtsenc
$

(BTW: My plan is to hack in a progress-indicator and Win32 Unicode support)

:thanks:

[amtm]

That's a good point. AVI-Mux GUI might use it as well
( however nobody but Alex Noe himself would want to rewrite and recompile the source-code, apparently :( )

Is it really that bad? :p :D Maybe I'll give it a look over one of these days amongst all the other projects I have going on. :p

[Midzuki]

@Midzuki:

What build environment did you use to make the Win32 build? MSYS+MinGW?

Yesss :)

gcc.exe (XvidVideo.RU - GCC 4.5.2 i686-pc-mingw32) 4.5.2

Also, and IIRC :o ,

"./configure --disable-alsa"

(BTW: My plan is to hack in a progress-indicator and Win32 Unicode support)

YAY! :cool:

[Midzuki]

Is it really that bad? :p :D

Well, I still haven't seen any "AVI-Mux GUI Mod" builds :p

Maybe I'll give it a look over one of these days amongst all the other projects I have going on. :p

:thanks:

[LoRd_MuldeR]

Well, my problem is, that I don't have a 'configure' script yet. It needs to be generated with autoconf.

Can you tell me what version of autoconf (and from where) you used? I installed autoconf + perl + libcrypt, but get the error from above :(

[Midzuki]

Humm, that's weird :confused:
IIRC (again), I just downloaded the full package from Xhmikosr's site some months ago, and (probably) just discarded the 64-bit stuff.

Anyway:

$ autoconf --version
autoconf (GNU Autoconf) 2.67
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>

Hope this helps :o

[LoRd_MuldeR]

Okay, the good news is: I got autoconf working by re-installing MSYS with the official MSYS installer.

The bad news is that the configure script it produces is broken. At one point it uses some PKG_PROG_PKG_CONFIG variable that nowhere has been define before :rolleyes:

Had to hack configure.ac as well as Makefile.am to finally convince that ... to give me a Makefile. But now I am set up, I think, finally!

[Midzuki]

Great! :)

(BTW: My plan is to hack in a progress-indicator and Win32 Unicode support)

A listing of the valid frequencies and bitrates would be useful as well ;)

Cheers.

[LoRd_MuldeR]

For now, here is the progress indicator. Will look at other things at a later time ;)

[Midzuki]

Danke! :thanks:

Gonna test it A.S.A.P. :o

[amtm]

Great! :)



A listing of the valid frequencies and bitrates would be useful as well ;)

Cheers.

From the README for sample rate frequencies:

The sample rate must be one of the following values: 32000, 44100, 48000 or those divided by 2 or 4.

I don't see anything in the README about only accepting a certain range of bitrates but it does mention:

The approximate bitrate is specified in bits per second and may be rounded up by the library.

Also for channels:

Note that values greater than DCAENC_CHANNELS_3FRONT_2REAR always return an error now because their encoding requires the Xch extension that is undocumented and thus not implemented.

So nothing greater than 5.1 for now.

[Midzuki]

According to THE :) .pdf:

8 11.025 12 16 22.050 24 32 44.1 48 (kHz)

and...

(kbps)

32 56 64 96 112 128 192 224 256 320 384

448 512 576 640 768 960 1024 1152 1280

1344 1408 1411.2 1472 1536 1920 2048 3072 3840

[LoRd_MuldeR]

Here is a new version with Unicode support. Also, for convenience, I changed the third parameter from bit/s to kbit/s ;)

Repository:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/trees/master

[amtm]

According to THE :) .pdf:

8 11.025 12 16 22.050 24 32 44.1 48 (kHz)



Which is exactly what I and the README on gitorious said. All those sample rates fall under 32000, 44100, and 48000 or any of those values divided by 2 or 4. :)

Also with respect to the bitrates you listed, the encoder ends up rounding values up to one of those but it will accept any value you want to input except for anything less than 32000bps or higher than 6144000bps.

[Midzuki]

Well, both lame and twolame do care about listing the valid encoding bitrates and frequencies,

in order to ensure the end-user has been well-informed :)

[amtm]

Well, both lame and twolame do care about listing the valid encoding bitrates and frequencies,

in order to ensure the end-user has been well-informed :)

Like I said, the README on Gitorious does list the valid frequencies and he does note any bitrate will be potentially rounded up, but explicitly listing all valid bitrates would be good to do.

[amtm]

Here is a new version with Unicode support. Also, for convenience, I changed to third parameter from bit/s to kbit/s ;)

Repository:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/trees/master

But you don't seem to have modified his bitrate range check or the rounding math as well in dcaenc.c.

Edit: Never mind I see you scale the bitrate before it gets there back to bps.

[LoRd_MuldeR]

Removed off-topic posts. Please stay at topic and be nice to each other :)

In the meantime I added support for reading input from STDIN (must have a Wave header for now) and writing output to STDOUT.

(Attachment in previous post has been updated)

[b66pak]

thanks a lot...
_

L.E.
In the meantime I added support for reading input from STDIN (must have a Wave header for now)
how about an "-ignorelength" for +4gb wavs?
_

[LoRd_MuldeR]

how about an "-ignorelength" for +4gb wavs?

Not yet. But you should be able to pipe in such files via STDIN.

[LoRd_MuldeR]

If the input Wave file could not be read, dcaenc will now tell you why.

[Selur]

@LoRd_MuldeR: Thanks! for the patched version(s) :)

----

Using the patched version I tried:
ffmpeg -threads 8 -v -10 -y -i "D:\Encoding Output\test.mp3" -ac 2 -acodec pcm_s16le -f wav - | dcaenc - "D:\Encoding Output\test.dts" 128
ffmpeg -threads 8 -v -10 -y -i "D:\Encoding Output\test.mp3" -ac 2 -acodec pcm_s16le -f s16le - | sox --ignore-length --temp "D:\Encoding Temp" --buffer 2097152 -S -t raw -e signed-integer -2 -c2 -r48000 - -t wav - | dcaenc - "D:\Encoding Output\test.dts" 128
dcaenc "D:\Encoding Output\test.wav" "D:\Encoding Output\test.dts" 128
and all result in: "Wrong bitrate or sample rate!"

What am I doing wrong?

-> works when using bitrates >= 320 ;)

[Midzuki]

@ Lord_Mulder:

$ autoconf
configure.ac:11: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.

-.-

[Selur]

Is it just me or does "dcaenc test.wav test.dts 3072" cause dcaenc to freeze (on a 2.0 input wav)?

755, 1280, 1510 and 3072 work fine for 5.1.
320, 384, 448, 512, 576, 640, 755, 1280 and 1510 work fine for 2.0, but 3072 doesn't.

Cu Selur

[Midzuki]

I am no expert, but for 2.0 audio, and regarding the DCA compression, anything above 576kbps should be clearly labeled as "overkill".

[Selur]

probably, but atm. I'm not checking which values are same but which are possible. ;)

[Midzuki]

Anyway, that's not a bug, but a feature :) Why on Earth would someone want to "compress" by using a bitrate HIGHER than the original one? :D

[Selur]

No it would be a feature it dcaenc would complain, but it freezes. :/

btw. I second the '-ignore length' request, since:
ffmpeg -threads 8 -v -10 -y -i "Test-AC3-5.1.avi" -ac 6 -acodec pcm_s16le -f s16le - | sox --ignore-length --buffer 2097152 -S -t raw -e signed-integer -2 -c6 -r48000 - -t wav - | dcaenc - "test.dts" 755
and
ffmpeg -threads 8 -v -10 -y -i "Test-AC3-5.1.avi" -ac 6 -acodec pcm_s16le -f s16le - | sox -q --ignore-length -t raw -e signed-integer -2 -c6 -r48000 - -t wav - | dcaenc - "test.dts" 755
both stop with:
Could not open or parse "-".
Error: Data chunk not found!
ffmpeg -threads 8 -v -10 -y -i "Test-AC3-5.1.avi" -f wav - | dcaenc - "test.dts" 755
works, but I guess that to accept the sox output a '-ignorelength' would be needed :)

Cu Selur

Ps.: ffmpeg -threads 8 -v -10 -y -i "Test-AC3-5.1.avi" -f wav - | sox -V0 --ignore-length -t wav - -t wav - | dcaenc - "test.dts" 755 doesn't work either

[Midzuki]

Well-spotted :stupid:

Feel free to :uglylol: Patrakov (and/or Lord_Mulder) :D

[Selur]

okay, got sox working :) one needs to use '-t wavpcm' instead of '-t wav' :)

[Midzuki]

^ Thanks for finding and sharing :) :goodpost:

Hopefully in the next build Mulder will include a comprehensive manpage for dcaenc :devil: :p

[Midzuki]

A listing of the valid frequencies and bitrates would be useful as well.

Stupid me :o
all I had to was edit main.c :stupid:
Usage: dcaenc input.wav output.dts bits_per_second

Valid sample rates (in kHz):

8 11.025 12 16 22.05 24 32 44.1 48

Valid bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 768
960 1024 1152 1280 1344 1408 1411.2 1472 1536
:cool: :cool: :cool:

[Selur]

@midzuki: did you try the bitrates&frequencies?
for me with 48kHz
for 5.1 only 755, 1280, 1510 and 3072 worked
for 2.0 only 320, 384, 448, 512, 576, 640, 755, 1280 and 1510 worked
worked = did not cause a freeze, crash and were really created

Cu Selur

[Midzuki]

^ @ Selur: not yet :o , I'm still trying to do 10 things at the same time :eek:
I will post my findings A.S.A.P.

[Midzuki]

Initial results:

stereo@48kHz cannot be encoded below 320kbps
(just confirming)

stereo@44.1kHz cannot be encoded below 256kbps

mono@48kHz cannot be encoded below 192kbps

Probably those limits were hard-coded by Patrakov himself; an outdated version of the DTSHD Encoder for example, was able to encode 48kHz mono at 126kbps (according to the respective manual, bien entendu).

worked = did not cause a freeze, crash and were really created

Over here, no freezing nor crashing, just a simple error message:

Wrong bitrate or sample rate

[dj_doc]

Just played around with LoRd_MuldeR's dcaenc build, sox and eac3to I used Hellboy Director's Cut German Blu-Ray rip

maybe someone will look for how to build a dts file from Blu-Ray PCM track


"c:\Program Files (x86)\RipBot264\Tools\eac3to\eac3to.exe" "e:\Blu-Rays\HELLBOY\" 1)
M2TS, 1 video track, 6 audio tracks, 21 subtitle tracks, 2:12:29, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: AC3, English, 5.1 channels, 448kbps, 48kHz
4: RAW/PCM, English, 5.1 channels, 16 bits, 48kHz
5: AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -30dB
6: AC3, German, 5.1 channels, 448kbps, 48kHz, dialnorm: -30dB
7: RAW/PCM, German, 5.1 channels, 16 bits, 48kHz
8: AC3 Surround, English, 2.0 channels, 192kbps, 48kHz, dialnorm: -26dB


Extract and Convert, don't forget do byteswap, and you're ready to mux your brand new dts track ;-)


"c:\Program Files (x86)\RipBot264\Tools\eac3to\eac3to.exe" "e:\Blu-Rays\HELLBOY\" 1) 7:stdout.wav -down16 -simple | sox -V0 --ignore-length -twavpcm - -t wavpcm - | dcaenc -i - -o "Hellboy_audio_German.dts" -l -b 1510

[Midzuki]

@ Lord_Mulder:

Would you mind releasing a "rarball" :p that can be compiled directly by MinGW

( id est, «just patch, configure and make» ) http://forum.doom9.org/images/icons/icon5.gif

[Selur]

Small question: When do we need the bytes swap step? Only when the dts later is ment for DVD production or when mplex is used?

[amtm]

Small question: When do we need the bytes swap step? Only when the dts later is ment for DVD production or when mplex is used?

From the behavior of eac3to as I've always seen it you want to make sure you always byteswap an LPCM track you extract from Blu-Rays. I could be wrong but any time I've reencoded an LPCM track from Blu-Ray to DTS or ac3 I believe it always byte swaps.

[dj_doc]

I agree

[Selur]

But what if the input is an ac3 or something else?

[amtm]

But what if the input is an ac3 or something else?

dj_doc's statement only had to do with using Blu-Ray PCM tracks. I don't think you need to do anything if your source is ac3 or another DTs track, etc.

[dj_doc]

I only tested with PCM but have a look at http://aepatrakov.narod.ru/dcaenc/command_line_encoder/ yourself

[LoRd_MuldeR]

@ Lord_Mulder:

Would you mind releasing a "rarball" :p that can be compiled directly by MinGW

( id est, «just patch, configure and make» ) http://forum.doom9.org/images/icons/icon5.gif

You can clone the code directly from my Git repository (http://gitorious.org/~mulder/dtsenc/mulders-dtsenc) and build, just as you (probably) did with the original version.

Or, if you already cloned the original repository, just add my repository as another "remote" and then pull the changes from there.

In the mean time, I improved the progress indicator if the exact input length isn't known (previous post (http://forum.doom9.org/showpost.php?p=1546200&postcount=26) updated).

[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.

[Selur]

In the mean time, I improved the progress indicator if the exact input length isn't known.
Nice!

[Midzuki]

You can clone the code directly from my Git repository (http://gitorious.org/~mulder/dtsenc/mulders-dtsenc) and build, just as you (probably) did with the original version.

As I had said some posts ago:

@ Lord_Mulder:

$ autoconf
configure.ac:11: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.

-.-

[LoRd_MuldeR]

I had problems with 'autoreconf' too. Had to comment out the check for ALSA, because otherwise I got some error with pkg-conf. Passing "--diable-alsa" didn't help.

Anyway, can't you build the modified dcaenc the same way you did it the first time? I have not changed anything about the build script, except for the pkg-conf workaround.

There is a new file, unicode_support.c, which has to be compiled in now. I simply hacked it into the generated Makefile manually ;)

[b66pak]

@LoRd_MuldeR please disable the percentage progress for STDIN input (is misleading)...

example:
Source: -
Output: audio.dts
KBit/s: 1510
Encoding... 0:00 [0.0%]
Encoding... 0:01 [0.0%]
Encoding... 0:02 [0.1%]
Encoding... 0:04 [0.1%]
Encoding... 0:05 [0.1%]
Encoding... 0:06 [0.2%]
Encoding... 0:08 [0.2%]
Encoding... 0:09 [0.3%]
Encoding... 0:10 [0.3%]
Encoding... 0:12 [0.3%]
Encoding... 0:13 [0.4%]
Encoding... 0:14 [0.4%]
Encoding... 0:16 [0.4%]
Encoding... 0:17 [0.5%]
Encoding... 0:18 [0.5%]
Encoding... 0:20 [0.5%]
Encoding... 0:21 [0.6%]
Encoding... 0:22 [0.6%]
Encoding... 0:24 [0.6%]
Encoding... 0:25 [0.7%]
Encoding... 0:26 [0.7%]
Encoding... 0:28 [0.8%]
Encoding... 0:29 [0.8%]
Encoding... 0:30 [0.8%]
Encoding... 0:32 [0.9%]
Encoding... 0:33 [0.9%]
Encoding... 0:34 [0.9%]
Encoding... 0:36 [1.0%]
Encoding... 0:37 [1.0%]
Encoding... 0:38 [1.0%]
Encoding... 0:40 [100.0%]
Done.
Process terminated with code: 0
Execution took 5 seconds(s).


it should be only:
Source: -
Output: audio.dts
KBit/s: 1510
Encoding... 0:00
Encoding... 0:01
Encoding... 0:02
Encoding... 0:04
Encoding... 0:05
Encoding... 0:06
Encoding... 0:08
Encoding... 0:09
Encoding... 0:10
Encoding... 0:12
Encoding... 0:13
Encoding... 0:14
Encoding... 0:16
Encoding... 0:17
Encoding... 0:18
Encoding... 0:20
Encoding... 0:21
Encoding... 0:22
Encoding... 0:24
Encoding... 0:25
Encoding... 0:26
Encoding... 0:28
Encoding... 0:29
Encoding... 0:30
Encoding... 0:32
Encoding... 0:33
Encoding... 0:34
Encoding... 0:36
Encoding... 0:37
Encoding... 0:38
Encoding... 0:40
Done.
Process terminated with code: 0
Execution took 5 seconds(s).

_

[LoRd_MuldeR]

The percentage indicator is disabled for STDIN.

More specifically, the progress indicator will be disabled if the reported size of the "data" chunk is either '0' or '0xFFFFFFFF', as is expected when reading from STDIN.

If whatever application you are piping the Wave data from reports a valid (i.e. neither zero nor UINT_MAX) but wrong size, then I think it should be fixed on that application's side.

Generally disabling the percentage indicator for STDIN is not a good idea, because I may pipe in a local file, in which case the total size is known just fine...

(Actually what we need is a proper "--ignore-length' parameter. But currently dcaenc does not parse the parameters. It just expects the 1st/2nd/3rd parameter is in/out/bitrate)

[b66pak]

Ok...
_

[Midzuki]

Anyway, can't you build the modified dcaenc the same way you did it the first time?

If I could, I would NOT have asked for help -.-

[amtm]

Since I don't see anything in the code that really requires MSYS, as we aren't going to use the ALSA plugin on Windows, when I get home in about 2 hours I'm going to create a Visual Studio solution for the code for far easier building. It's just pretty plain jane C code that can easily be compiled with Visual Studio.

[LoRd_MuldeR]

If I could, I would NOT have asked for help -.-

Then you should find out what has changed in your environment since the time when the build script still worked for you, I think.

As said before, I did not change anything that should effect the build script. I only modified 'main.c' as well as 'wavefile.c' and added 'unicode_support.c' + '...h'.

If you have some configuration that builds the original version (which you obviously had at one point), copy over those four files and you are done :)

[Midzuki]

I only modified 'main.c' as well as 'wavefile.c' and added 'unicode_support.c' + '...h'.

...

copy over those four files and you are done :)

OK...

$ make
make all-am
make[1]: Entering directory `/f/xperiments/mulder'
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -g -O2 -MT dcaenc.lo -MD
-MP -MF .deps/dcaenc.Tpo -c -o dcaenc.lo dcaenc.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -g -O2 -MT dcaenc.lo -MD -MP -MF .deps/dcaenc.Tpo -c
dcaenc.c -DDLL_EXPORT -DPIC -o .libs/dcaenc.o
mv -f .deps/dcaenc.Tpo .deps/dcaenc.Plo
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT gentables.o -MD -MP -MF .deps/gentables.Tpo -c -o gentabl
es.o gentables.c
mv -f .deps/gentables.Tpo .deps/gentables.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o gentables.exe gentables.o -lm
libtool: link: gcc -g -O2 -o .libs/gentables.exe gentables.o
./gentables.exe >math_tables.c
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -g -O2 -MT math_tables.l
o -MD -MP -MF .deps/math_tables.Tpo -c -o math_tables.lo math_tables.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -g -O2 -MT math_tables.lo -MD -MP -MF .deps/math_tabl
es.Tpo -c math_tables.c -DDLL_EXPORT -DPIC -o .libs/math_tables.o
mv -f .deps/math_tables.Tpo .deps/math_tables.Plo
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -version-info 0:0:0 -export-symbols ./dcaen
c.sym -o libdcaenc.la -rpath /usr/local/lib dcaenc.lo math_tables.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
libtool: link: ar cru .libs/libdcaenc.a .libs/dcaenc.o .libs/math_tables.o
libtool: link: ranlib .libs/libdcaenc.a
libtool: link: ( cd ".libs" && rm -f "libdcaenc.la" && cp -p "../libdcaenc.la" "libdcaenc.la" )
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c: In function 'dcaenc_main':
main.c:71:2: error: too many arguments to function 'wavfile_open'
wavfile.h:34:11: note: declared here
main.c:86:61: warning: pointer/integer type mismatch in conditional expression
main.c:113:47: error: 'UNKNOWN_SIZE' undeclared (first use in this function)
main.c:113:47: note: each undeclared identifier is reported only once for each function it appea
rs in
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/f/xperiments/mulder'
make: *** [all] Error 2

[Midzuki]

@ Lord_Mulder

In summary: for your modified source-code,

-- autoconf = FAIL

-- autoreconf = FAIL

-- make = FAIL

Well, I still can compile x264, bdtools, L-Smash audiomuxer and twolame
(not to mention the original dcaenc),
so my MSYS+MinGW environment is not as screwed as you want me to think. ;)

[LoRd_MuldeR]

As said before, I did not change anything related to autoconf, except for commenting out the ALSA check.

This was done, because I couldn't get pkg-config to work in my build environment. If pkg-config works for you, then you don't need these modifications.

So, if you have a working Makefile (which you obviously had at one point) and then just throw in the .c and .h files I modified, that Make won't suddenly stop working.

Thus you should be able to build with that Makefile. If your Makefile doesn't work, then you obviously changed more than just the .c and .h files I modified.

Also note that if you don't want to update the autoconf files for the new .c file, you will have to hack in that one file into your existing Makefile. That's what I did.

BTW: Added a workaround for a possible livelock. Not really a solution, as the application will now abort in that case. At least it doesn't freeze anymore.

[Midzuki]

As said before, I did not change anything related to autoconf, except for commenting out the ALAC check.

This was done, because I couldn't get pkg-config to work in my build environment. If pkg-config works for you, then you don't need these modifications.

So, if you have a working Makefile (which you obviously had at one point) and then just throw in the .c and .h files I modified, that Make won't suddenly stop working.

Thus you should be able to build with that Makefile. If your Makefile doesn't work, then you obviously changed more than just the .c and .h files I modified.

Also note that if you don't want to update the autoconf files for the new .c file, you will have to hack in that one file into your existing Makefile. That's what I did.

BTW: Added a workaround for a possible livelock. Not really a solution, as the application will now abort in that case. At least it doesn't freeze anymore.

It would be interesting to know if I really am the only one who is having bad-luck with your modded source-code? :confused:

Anyway, I'd better stop insisting on what does not work for me :(

"Obviously" :rolleyes: I'd rather compile a "normal" and "working" source-code:

configure, make, enjoy :-)

Happy Easter anyway and BTW :)

[amtm]

The altered code throws all sorts of errors in Visual Studio as well while the unaltered code compiles just fine.

[LoRd_MuldeR]

The altered code throws all sorts of errors in Visual Studio as well while the unaltered code compiles just fine.

Any details? Compiles just fine in GCC.

[amtm]

Any details? Compiles just fine in GCC.

When compiling as C it doesn't like how you mix declarations within the code for one thing as it's applying C89 semantics so it means I have to restructure a bunch of your code. I can compile it as C++ but then it throws errors about casting and other problems. Of course none of these are unfixable, it's just that it won't compile straight off.

[LoRd_MuldeR]

I see. If you share your VS project/solution file, I can fix the code for the MSVC compiler. Shouldn't be a big deal.

[amtm]

If you share your VS project/solution file, I can fix the code for the MSVC compiler.

No need, I already fixed it all. Just letting you know that the code you have as is won't compile without changes.

[LoRd_MuldeR]

I'd still like to fix it on my side too. And I'd prefer compiling in Visual Studio. So if you can share your project/solution file, this would be much appreciated :)

[amtm]

I'm out right now. When I get back home in an hour or so I'll clone your repo and send you a pull request.

[LoRd_MuldeR]

Never mind, got it working:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/bf237b4be59b08b99968608b57fd383fde82bdd0

Interestingly the MSVC build runs a lot slower...

[Midzuki]

then you obviously changed more than just the .c and .h files I modified.

Wrong, it's you who still hasn't learned how and when to write an answer that goes "straight to the point" ;)

autoreconf --INSTALL

configure --disable-alsa

make

enjoy ;-P

:) :p :D

[Selur]

btw. the MSVC project gives me:
1>c1 : fatal error C1083: Cannot open source file: '..\math_tables.c': No such file or directory
1>..\main.c(23): fatal error C1083: Cannot open include file: 'config.h': No such file or directory

[Midzuki]

Not-So-Humble Suggestion: while neither Patrakov not amtm manage to improve the encoder itself, the file main.c should include the following "mandatory"...

WARNING:
Currently not all possible combinations of frequencies and bitrates are supported.

[LoRd_MuldeR]

btw. the MSVC project gives me:
1>c1 : fatal error C1083: Cannot open source file: '..\math_tables.c': No such file or directory
1>..\main.c(23): fatal error C1083: Cannot open include file: 'config.h': No such file or directory

Sure you have the solution/project file in the "vc_solution" sub-folder, as I have checked in the stuff?

If you put the project file into the "root" folder (i.e. where all the .c and .h files are located), you'll have to remove the "..\" from all paths (in the .vcprojx file)

[Selur]

here's what I did
1. I checked out git://gitorious.org/~mulder/dtsenc/mulders-dtsenc.git to G:\workspace\dtsenc
2. went to the vc_solution subfolder and double clicked the vcproj file for MSVC to start up and import the content
3. changed 'Debug' to 'Release' and started the build process
4. ended up with the error message

moving the lsn and vcxproj file and editing it (removing the ../) just changed the error a bit:
1> dcaenc.c
1> main.c
1> math_tables.c
1> unicode_support.c
1>c1 : fatal error C1083: Cannot open source file: 'math_tables.c': No such file or directory
1> wavfile.c
1>main.c(23): fatal error C1083: Cannot open include file: 'config.h': No such file or directory

Cu Selur

[LoRd_MuldeR]

It seems "math_tables.c" and "config.h" are indeed missing from the repository.

The strange thing is, they don't even exist in the original repository. Well, the config file was probably created by the configure script.

Anyway, I will commit the missing files as soon as I return home...

[nu774]

It seems "math_tables.c" and "config.h" are indeed missing from the repository.
As you know, config.h is usually generated by a configure script, and that's the main purpose of configure.
math_tables.c is automatically generated while making.
(At first, a program named gentables is compiled from gentables.c, and math_tables.c is generated by running it).

This means that you must to be able to run the target binary (gentables) while making.
This can be a problem when you do cross compilation.

[LoRd_MuldeR]

It seems "math_tables.c" and "config.h" are indeed missing from the repository.

The strange thing is, they don't even exist in the original repository. Well, the config file was probably created by the configure script.

Anyway, I will commit the missing files as soon as I return home...

Should be fixed now :)

[Selur]

Thanks! Works here now! :)

Cu Selur

[b66pak]

@LoRd_MuldeR the MSVC builds are slow...can you also add a build with the previous method (MSYS+MinGW?)...
_

[LoRd_MuldeR]

MSVC builds are slow...

As I said... :o

can you also add a build with the previous method (MSYS+MinGW?)...

I posted MinGW/GCC builds earlier. Anyway, with MSVC+ICL the speed is approximately the same as with GCC - build attached.

Also tried to make x64 builds, but output is broken! I have no idea why that is yet...

[b66pak]

thanks a lot...
_

[Midzuki]

At last... :)

[F:\XPERIMENTS\mulder\.libs]
=>dcaenc
dcaenc-1 [Dec 24 2011]

Usage: dcaenc <input.wav> <output.dts> <bitrate_kbps>

NOTICE:
Input or output file name can be "-" for stdin/stdout.

* Valid sample rates (in kHz):

8 11.025 12 16 22.05 24 32 44.1 48

* Valid bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 754.5
960 1024 1152 1280 1344 1408 1411.2 1472
1509 1920 2048 3072 3840 open VBR LOSSLESS

WARNING:
Currently not all possible combinations of frequencies and bitrates are supported.

... and ......

[F:\XPERIMENTS\mulder\.libs]
=>dcaenc --version
dcaenc-1 [Dec 24 2011]
dcaenc-1
http://aepatrakov.narod.ru/dcaenc/

Binaries will be available "very soon" :confused: , BUT,
quite probably,
not on my Skydrive :devil: folder :(

[ E D I T ]

P.S.: That's not good-enough yet :( One must clearly state,
"this is an experimental DCA compressor" or something -.-

P.P.S.: Last but not least,

"original code by Patrakov",

"major improvements by Lord_Mulder",

whatever.

[Selur]

What's the meaning/effect of 'open' and 'VBR' for bitrates?

Currently not all possible combinations of frequencies and bitrates are supported.
if anyone has a list please share :)
48kHz 2 Channel works with: 320 384 448 512 576 640 (I would recommend 576 since at least my receiver doesn't like 640 ;))
48kHz 5.1 Channel works with: 755 1280 1509 3072 (I would recommend 1510 since 3072 seems like overkill ;))

Cu Selur

[Midzuki]

^

Originally posted by THE :) .PDF :

The open mode allows for bit rates not defined by the table.

Variable and loss-less modes imply that the data rate changes from frame to frame.

if anyone has a list please share

That's a W.I.P. :) , please be patient :D

[Midzuki]

...
48kHz 5.1 Channel works with: 755 1280 1509 3072 (I would recommend 1510 since 3072 seems like overkill ;))

Just my useless :rolleyes: thoughts:

Many people think/say 5.1 DTS @ 44.1kHz @ 1234.8kbps is [ place your favorite superlative here :) ]. However, that's mathemagically-equivalent to 1344kbps @ 48kHz. In other words, 1509kbps has been overkill since the very-beginning :p

And considering movie soundtracks ARE N0T Audio-CDs ;) ,
probably in most cases 1280, 1152, 1024, or even 960, kbps would have been more-than-adequate for them. :devil:

[Selur]

Since my Hardware decoder only supports 576kBit/s for stereo, I'll stick to the standard 1510 to be save. ;)

[Midzuki]

Hummm, maybe you should SUE :devil: the manufacturer of your audio receiver --- they surely didN'T warn you that you were buying crippled firmware.

As for DTS, Inc. ...

you just give them some tons of money,
and they give you the right to use their logo :mad: :mad: :mad:

[Midzuki]

@ Selur: you've been using only the modded build, right?

Or not? :confused:

Because I have just tested the "unpatched" dcaenc on two short 5.1 .WAVs (at both 44.1kHz and 48kHz), and there were NO errors for all the valid bitrates between 754.5kbps and 1509kbps. And all the resulting samples played correctly with foobar2000.

:confused: :confused: :confused:

[Selur]

I tried both, but I never said that there's a problem with 5.1wav -> dts withc 41./48kHz and bitrates between 754.5kbps and 1509kbps,..
I stated:
1. 48kHz 5.1 Channel works with: 755 1280 1509 3072
2. 48kHz 2 Channel works with: 320 384 448 512 576 640
3. 48kHz 2 Channel with 3072 does not work (freezes)
4. I would recommend 576 since at least my receiver doesn't like 640 dts for 2.0
5. I would recommend to use 1509 for 5.1 dts :)

Than you insinuated that 1509 might be overkill and I replied that I stick with 1509 due to the fact that my receiver is picky.
(and it's probably not the only hardware receiver that only accepts specific bit rates; mine also does accept all the bit rates (755+) for 5.1 audio, but since it's picky with 2.0 material I will stay with the common 1509kBit/s for 5.1 audio)

Cu Selur

[Midzuki]

Honestly, I don't know who is misunderstanding who -.-

@midzuki: did you try the bitrates&frequencies?
for me with 48kHz
for 5.1 only 755, 1280, 1510 and 3072 worked
for 2.0 only 320, 384, 448, 512, 576, 640, 755, 1280 and 1510 worked
worked = did not cause a freeze, crash and were really created

Cu Selur

[Selur]

LOL me neither :) btw. Merry Christmas to all reading this. :)

[phate89]

Merry crhistmas to everyone!

[Midzuki]

Thanks and thanks :)

So, in order to make things as clear as possible:

5.1 + 44.1kHz IS correctly compressed at
754.5, 960, 1024, 1152, 1280, 1344, 1408, 1411.2, 1472, and 1509 kilobits per second ;

5.1 + 48kHz IS correctly compressed at
754.5, 960, 1024, 1152, 1280, 1344, 1408, 1472, and 1509 kilobits per second ;

[Midzuki]

Just a couple of random thoughts...

1) According to the file ts_102114v010301p.pdf ("ETSI TS 102 114 V1.3.1 [2011-08]"), the «targeted bitrates» above 1536kbps, together with the types "VBR" and "lossless", have been declared `invalid´ :scared:

2) (to whom this may interest) In the versions of the DTSHD Encoder Suite released after the death of the HD-DVD format, the following bitrates (in kbps) are not available: 576, 1024, 1280, 1408, 1472; for the frequency 44.1kHz, only the "Audio-CD bitrate" (1411.2) plus the 5.1 channel layout can be chosen ( as usual :rolleyes: )

3) Apparently the Hydrogenaudio people don't care at all about dcaenc :confused:

[b66pak]

Actually what we need is a proper "--ignore-length' parameter. But currently dcaenc does not parse the parameters. It just expects the 1st/2nd/3rd parameter is in/out/bitrate

@LoRd_MuldeR...you can force the size of the data chunk to zero (0000 0000) or -1 (FFFF FFFF) for input for file or pipe...

by design the encoder will read the data till the end...this way is done a proper encode for +4gb wav files...this way also is done a proper encode when pipeing large files with tools like eac3to or sox...

the only downside i see, is loosing the percentage counter for input from files...but you can overcome this by determining the duration of the audio file from its file size using this formula:

D = 8*S /(C*B*R)

where:

D is duration of the file in seconds

S is the size of the file in bytes (the header is to small to count - so no need to subtract it)

C is the number of the channels

B it the bitdepth in bits

R is the sampling rate in Hz


example:

for a 207,360,044 bytes 6 ch, 16 bit, 48000 Hz file the duration will be:

D = 8*207,360,044 /(6*16*48000) = 360 seconds

i hope you will consider this...
_

[LoRd_MuldeR]

Actually my dcaenc-mod will ignore the input length, if the length of the data chunk is given as either 0x00000000 or 0xFFFFFFFF ;)

However I have no control over what the individual source application writes to the Wave file!

It is expected that the application would write 0x00000000 or 0xFFFFFFFF, iff the actual size isn't known yet (e.g. application is writing to STDOUT) or exceeds 4 GB.

But if the application wrote a valid size, i.e. bigger than 0x00000000 and smaller than 0xFFFFFFFF, then I will assume that size is the actual/correct size.

(So if some application writes a valid but wrong size to the Wave file, that application has to be fixed)

[Selur]

would it be possible to add an cli option to make sure the length is ignored? (not sure what sox will write into the header for 4gb+ files,..)

Cu Selur

[b66pak]

only ffmpeg (zero) and wma2wav (FFFF FFFF) can do that...please force the value so we can use eac3to (FFFF FF00) and sox (7FFF EFFC) too!
_

let me reformulate...please ignore the input length for any value...there is nothing wrong in doing this...
_

[LoRd_MuldeR]

There is much wrong with ignoring the input length for any value!

In order to show a progress indicator - and that was one of the primary reasons for my modifications - we have to know the total size of the data chunk.

So if the Wave file has a valid/reasonable length for it's "data" chunk, we will assume that this is the actual size of the data chunk.

I could add a hack to ignore the length if it is 0xFFFFFF00, if that is what 'eac3to uses' to indicate an unknown size. However 0x7FFFEFFC is a perfectly valid value (~2 GB).

Again: The right solution would be adding a "--ignore-length" parameter to dcaenc. But it's hard to do, as dcaenc doesn't have a real parameter parser yet.

I will put this on the long-term TODO list. Currently I'm working on getting my modifications merged...

[b66pak]

please read again my post (http://forum.doom9.org/showthread.php?p=1547172#post1547172)...i presented an alternate solution for the progress indicator (the percentage counter)...
_

also eac3to uses 0xFFFFFF00 only when decode a file to wav...when passes a wav to stdout it forwards the value found in the wav header which is wrong if the file is +4gb...so patching 0xFFFFFF00 is only a partial solution...same stuff for sox too...
_

[LoRd_MuldeR]

Using the total size of the file to determine the total duration is not very reliable for several reasons :(

For example, when reading from STDIN, we cannot seek or get the total size - obviously.

And even when reading from a physical file, we cannot determine the total duration reliably from the file's size.

That's because only the size of the "data" chunk would be relevant. But there may be other chunks after the "data" chunk.

If some applications write "bad" Wave headers, let's fix these apps rather than inventing dubious workarounds...

(I guess 0xFFFFFF00 is 4 GB minus the preceding RIFF-header, but I have no idea for what reason 0x7FFFEFFC is chosen)

[Midzuki]

Just out of curiosity, what would be the E.T.A. for adding support for (up to 6) mono inputs ???

Notice, "never" IS a valid answer :)

[tebasuna51]

Another feature request.

I see dcaenc output Little-Endian dts.
I know is a valid option compliant with DTS specs, but maybe output Big-Endian dts is a better option because:

- Some software can't recognize LE DTS (eac3to at least, no problem with NicAudio-libdts decoder), mi Yamaha receiver don't play LE DTS (sending by SPDIF with mpc-hc),.... Without problems with BE DTS
- I never see LE DTS in DVD or BD, always BE.
- Other commercial encoder (Surcode, Master Audio Suite) always output BE DTS.

[nevcairiel]

Outputting BE data on a LE system is always rather annoying, which is why he probably opted to not include it for the time being but instead recommend that you byteswap it afterwards with ie. ffmpeg.

ffmpeg -ar 48000 -ac 2 -f s16le -i output.dts -f s16be output_be.dts

[Midzuki]

ffmpeg -ar 48000 -ac 2 -f s16le -i output.dts -f s16be output_be.dts

But swab.exe would be much simpler :)

swab input_file output_file

[tebasuna51]

Outputting BE data on a LE system is always rather annoying...
Sorry by my ignorance but, what LE system?
Do you need convert dts from DVD's, BD's and comercial encoders to LE dts?

BTW, using ffmpeg with my first sample the last frame is cut by 4 bytes, then the last frame is incomplete and not decoded.

[nevcairiel]

Sorry by my ignorance but, what LE system?

Every x86 system is natively Little-Endian.
Big-Endian native systems have been gone out of style, really. Some ARM systems can be big-endian, though


Do you need convert dts from DVD's, BD's and comercial encoders to LE dts?

No you don't because most decoders are smart enough to read both LE and BE (especially with BE being the common standard)


BTW, using ffmpeg with my first sample the last frame is cut by 4 bytes, then the last frame is incomplete and not decoded.

Using ffmpeg just to byteswap is really a hack, to do it properly should be using a "real" byte-swapping tool.

[Selur]

I agree a option you select if the output is LE or BE would be nice (and would save an additional ffmpeg/swap/whateverstep if BE is needed; btw. my onky receiver has not problem with be or le)

[tebasuna51]

Every x86 system is natively Little-Endian.
Yes.
But I'm working with a x86 system and I have problems with LE DTS.

Maybe is because splitters/decoders stand for BE DTS
(especially with BE being the common standard)

[Midzuki]

^ Yet another application that doesn't swallow Little-Endian DTS:

AVI-Mux GUI

[LoRd_MuldeR]

Well, I'm not an expert on the DCA bitstream format.

But I think simply chopping the DCA stream into 16-Bit words and then inverting the byte-order of each word is not the correct way to convert between LE/BE endianness.

There may be fields in the stream that are not exactly 16-Bit, but bigger or smaller than that. If so, this would have to be implemented directly in the encoder library.

Any comments? :confused:

[Midzuki]

When converting a LE-DTS to a BE-DTS through swab and bsconvert, the respective outputs are byte-by-byte identical.

According to the latest .PDF, the little-endian order is the default for the LBR streams only :confused:

[nevcairiel]

I think simply chopping the DCA stream into 16-Bit words and then inverting the byte-order of each word is not the correct way to convert between LE/BE endianness.

Actually, thats how it seems to work for DCA.
I looked over ffmpegs DCA decoder, and when it finds a LE stream it byte-swaps it just like that into BE, because the native decoder mode is BE.

I think it works like that because DTS can also be put on a CD, and CDs always store stuff in 16-bit words.

Also, it seems to work, empirical evidence ftw?! :D

[Midzuki]

In case of doubt, just send an e-mail to Alexander Vigovsky (http://ac3filter.net/) :D

[nu774]

hint: DCAENC_FLAG_BIGENDIAN
http://aepatrakov.narod.ru/dcaenc/shared_library/

Tiny modification to main.c will be enough.

[LoRd_MuldeR]

hint: DCAENC_FLAG_BIGENDIAN
http://aepatrakov.narod.ru/dcaenc/shared_library/

Tiny modification to main.c will be enough.

Sometimes things can be so easy :)

So does this mean I should compile with DCAENC_FLAG_BIGENDIAN in the future, because BE streams are more common and more widely supported?

(Yes, this should be a runtime CLI option, but you know, no command-line parser yet, etc, etc ^^)

[Midzuki]

@ nevcairiel:

Interesting finding:

LAV splitter ++ ArcSoft decoder ++ BE-DTS stereo == "detected as" 2.0

but

LAV splitter ++ ArcSoft decoder ++ LE-DTS stereo == "detected as" 7.1 :eek:

:confused: :confused: :confused: :confused: :confused:

[nevcairiel]

@ nevcairiel:

Interesting finding:

LAV splitter ++ ArcSoft decoder ++ BE-DTS stereo == "detected as" 2.0

but

LAV splitter ++ ArcSoft decoder ++ LE-DTS stereo == "detected as" 7.1 :eek:

:confused: :confused: :confused: :confused: :confused:

My header parser is probably not capable to handle LE DTS, because i never had a file in my hands before. :)
Since i'm lazy, if you could put a small file somewhere to check out, that would be great.

[LoRd_MuldeR]

@ nevcairiel:

Interesting finding:

LAV splitter ++ ArcSoft decoder ++ BE-DTS stereo == "detected as" 2.0

but

LAV splitter ++ ArcSoft decoder ++ LE-DTS stereo == "detected as" 7.1 :eek:

:confused: :confused: :confused: :confused: :confused:

That may be one of the funny effects that you get when assuming all fields are 16-Bit during the endianess-conversion, when they actually are not.

[nevcairiel]

That may be one of the funny effects that you get when assuming all fields are 16-Bit during the endianess-conversion, when they actually are not.

Thats not the reason for it, my dts header parsing code just isn't written to deal with LE DTS, because its rather uncommon.
I read some more documentation on the matter, and the way of byteswapping seems to be the right thing to do.

[tebasuna51]

The native byte order for DTS streams is BE, but can be stored in 4 formats: 16BE, 16LE, 14BE and 14LE

"When DTS bit stream is stored in 16-bit words such as on CD, SYNC will be stored as 0x7ffe and 0x8001. However, when DTS bit stream is viewed on an IBM PC platform, since the high byte and low byte are switched, SYNC will appear like 0xfe7f and x0180.
Note that, in order to make the harsh sound less unpleasant when DTS bit stream is mistakenly played back as PCM format, DTS now provides a 14-bit format that reduces the dynamic range from 16 to 14 bits. In this 14-bit format, DTS bit stream is stored only in the least significant 14 bits of a 16-bit word, the most significant 2 bits are not used, In case of this, SYNC is stored in three words: 0x1fff, 0xe800, and 0x07f. "

The first task of the decoder is convert any format to 16BE, and now read the header fields with different size in bits (without byte or word boundaries):

Fields in DTS header bits Typical example values [cdaenc]
----------------------------- ---- ------------------------------------
Header sync.................. 32 0x7ffe8001
Normal frame................. 6 63 (No termination frame)
CRC present ................. 1 0 (Not)
Number of PCM Sample Blocks . 7 15 ( 512 samples/frame)
Primary Frame Byte Size ..... 14 2011 ( 2012 bytes/frame)
Audio Channel Arrangement ... 6 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency .. 4 13 (48 kHz)
Transmission Bit Rate ....... 5 24 (1536 Kb/s)
Embedded Down Mix Enabled ... 1 0 (Not)
Embedded Dynamic Range Flag . 1 0 (Not)
Embedded Time Stamp Flag .... 1 0 (Not)
Auxiliary Data Flag ......... 1 0 (Not)
Mastered in HDCD format ..... 1 0 (Not)
Extension Audio Descr. Flag . 3 0 (Channel Extension XCh)
Extended Coding Flag ........ 1 0 (Not)
Audio Sync Word Insert. Flag 1 0 (Sub-frame)
Low Frequency Effects Flag .. 2 2 (Present, interpolation factor 64)
Predictor History Flag Switch 1 1 (Yes)
(CRC if CRC present)......... (16)
Multirate Interpolator Switch 1 0 (Non-perfect Reconstruction)
Encoder Software Revision ... 4 7 (Current)
Copy History ................ 2 0 (Definition deliberately omitted)
Source PCM Resolution ....... 3 0 (16 bits) [also for 24 bit source]
Front Sum/Difference Flag ... 1 0 (Not)
Surrounds Sum/Difference Flag 1 0 (Not)
Dialog Normalization Param. . 4 - 0 dB

My conclusions:

- The swab.exe method is sure to convert 16LE to 16BE

- The prefered output mode must be 16BE

EDIT:
Exact bitrate must be calculated with Samplerate, Number of PCM Sample Blocks and Primary Frame Byte Size. Here:

Bitrate = 8 x 2012 x 48000 / 512 = 1509000 bits/s = 1509 Kb/s

This is the bitrate when commercial encoders output compact DTS (.cpt), when output padded DTS (.dts) the frames are incremented with bytes '0' until reach Transmission Bit Rate.
Here add 36 '0' at the end of the 2012 frame to reach 1536 Kb/s.

[LoRd_MuldeR]

Added an actual command-line parser. Also added some useful options. Run with "-h" for details!

[Selur]

Nice! Thanks!

[Midzuki]

Added an actual command-line parser. Also added some useful options. Run with "-h" for details!

Hummm, AVI-Mux GUI liked it.

So it seems that it's working :p :)

dcaenc-1 [Dec 30 2011]

blah-blah-blah :-D

Usage:
dcaenc -i <input.wav> -o <output.dts> -b <bitrate_kbps>

Optional:
-l Ignore input length, can be useful when reading from stdin
-e Switch output endianess to Little Endian (default is: Big Endian)
-h Print the help screen that your are looking at right now
-v Show version info

:thanks: :thanks: :thanks:

[phate89]

about using little endian is not better -le that reminds little endian than the simple -e?

[tebasuna51]

Sorry but don't work here (XP SP3 32 bits) with the new:
dcaenc.exe 147.968 bytes 30/12/2011 00:07

With the two encodes:
dcaenc -i 6chan.wav -o be.dts -b 1509
dcaenc -i 6chan.wav -o le.dts -b 1509 -e

I have be.dts and le.dts bit-identical and 16LE
With:
swab le.dts fix.dts

I get a correct 16BE header but with:
Low Frequency Effects Flag ..: 0 (Not present)

Decoded with ArcSoft or NicAudio I get:
5 channels, all the same, with a mix of 6 original channels.

With NicAudio I can decode also original le.dts with the same result.

Using the previous version:
dcaenc.exe 146.432 bytes 23/12/2011 22:11

and:
dcaenc 6chan.wav le_old.dts 1509
swab le_old.dts fix_old.dts

The fix_old.dts is all ok.

[LoRd_MuldeR]

tebasuna51, I think I found a bug!

For 6ch input, instead of adding the DCAENC_FLAG_LFE flag, I removed all flags except for DCAENC_FLAG_LFE :o

Will upload a fixed version ASAP.

[LoRd_MuldeR]

tebasuna51, I think I found a bug!

For 6ch input, instead of adding the DCAENC_FLAG_LFE flag, I removed all flags except for DCAENC_FLAG_LFE :o

Will upload a fixed version ASAP.

Build in previous post (http://forum.doom9.org/showpost.php?p=1547760&postcount=132) updated with fixed version!

[tebasuna51]

Now work fine.

Thanks Lord!

[Midzuki]

The good-boys shall not be :uglylol:ed :p

:thanks: again

P.S.: Now all that we need is a comprehensive manpage :D

[microchip8]

Works on Linux here with no issues. I'm adding support for it in h264enc and my other scripts :)

[b66pak]

comparing Midzuki's build (http://forum.doom9.org/showthread.php?p=1545951#post1545951) output dts with LoRd_MuldeR's output dts for the same audio input i found that LoRd_MuldeR's output is always one frame longer...
dcaenc-1 audio.wav audio.dts 1509000

dcaenc -i audio.wav -o audio.longer.dts -b 1509

[Input info] audio.dts
Bitrate=1536
Actual rate=1509.750000
Sampling Frec=48000
TotalFrames=3750
Bytesperframe=2012.0000
Filesize=7545000
FrameDuration= 10.6614
Framespersecond= 93.7966
Duration=00:00:39.980
Channels mode=C+L+R+SL+SR
LFE=LFE: Present
[Target info]
StartFrame=0
EndFrame=3749

[Input info] audio.longer.dts
Bitrate=1536
Actual rate=1509.750000
Sampling Frec=48000
TotalFrames=3751
Bytesperframe=2012.0000
Filesize=7547012
FrameDuration= 10.6614
Framespersecond= 93.7966
Duration=00:00:39.990
Channels mode=C+L+R+SL+SR
LFE=LFE: Present
[Target info]
StartFrame=0
EndFrame=3750

am i missing something?
_

[LoRd_MuldeR]

Does the -e switch make any difference? My build now outputs BE by default, Midzuki's build probably gives LE.

(Shouldn't make a difference, but you never know ^^)

[b66pak]

nope...anyway a heve noticed this problem before you implemented the command line parser (since dcaenc.2011-12-21)...dcaenc.2011-12-20 is OK...
_

[tebasuna51]

Both encoders fill a first frame (10.667 ms) with silence, then the full audio is delayed by this value.

dcaenc-1 cut the last 10.667 ms of audio, then the duration is the same than input audio

dcaenc don't cut nothing and need one more frame.

If we cut the first frame (with DelayCut for instance) of dcaenc encode we have same duration than source without delay.

Edit: test with 2.0 48 KHz at 755, and 5.1 48 KHz at 1509

[tebasuna51]

comparing ...

Your tool to analyze DTS seems inaccurate, must be (in red):
[Input info] audio.dts
Bitrate=1536
Actual rate=1509.750000 (1509.000)
Sampling Frec=48000
TotalFrames=3750
Bytesperframe=2012.0000
Filesize=7545000
FrameDuration= 10.6614 (10.6667)
Framespersecond= 93.7966 (93.7500)
Duration=00:00:39.980 (40.0000)

[LoRd_MuldeR]

comparing Midzuki's build (http://forum.doom9.org/showthread.php?p=1545951#post1545951) output dts with LoRd_MuldeR's output dts for the same audio input i found that LoRd_MuldeR's output is always one frame longer...dcaenc-1 cut the last 10.667 ms of audio, then the duration is the same than input audio

dcaenc don't cut nothing and need one more frame.


I think in the original version of 'dcaenc' the wavfile_read_s32() function had a design flaw :scared:

This function returned the current value of the Wave reader's internal 'samples_left' counter rather than the number of samples that have just been read. Also the 'samples_left' counter was decreased by the number of samples that have just been read before the function returned. Thus the function returned the state of the 'samples_left' counter after the current read operation! Consequently, when reading the very last samples from the Wave file, the 'samples_left' counter changed to zero and so the return value of wavfile_read_s32() also was zero. This caused the main() processing loop to exit right after the very last wavfile_read_s32() call, discarding all samples it just read. And, as the wavfile_read_s32() function reads up to 512 samples at once (actually it always returns 512 samples by filling the rest with zero-bytes, if necessary), up to 512 samples could be discarded. I changed the wavfile_read_s32() function to return the number of samples that have been read, i.e. in the current read operation. So if at least one sample was read, we go through the loop (at least) one more time and nothing can get discarded. This also was required with respect to the STDIN support and the "ignore length" option, where 'samples_left' is not known at all. All this doesn't explain the delay by one frame, but it may just be a property of the DCA encoding. MP3 encoders also cause some delay...

[tebasuna51]

I changed the wavfile_read_s32() function to return the number of samples that have been read
Correct.

All this doesn't explain the delay by one frame, but it may just be a property of the DCA encoding. MP3 encoders also cause some delay...
Yes, many encoders cause delays.

AC3 encoders cause 256 samples of delay (5.333 ms at 48 KHz). Only Aften have a parameter (-pad 0) to cancel the delay.

I think this silence delay is to avoid initial encoder artifacts when first samples have high volume.
AC3 encoders store the last 256 samples from previous frame to initialize the encode of next frame, maybe dcaenc need 512 samples.

[LoRd_MuldeR]

The potential live-lock in dcaenc has been fixed by the original author. I ported his fix to my branch and removed the old workaround.

[b66pak]

thanks a lot...
_

[Selur]

Thanks!
As a side note: Is it just me or do LoRd_MuldeRs binary get smaller and smaller each time? (not that I'm complaining, it's just an observation)

Cu Selur

[geminigod]

I feel privileged to be the first editor who is not a coder to jump in on this conversation and ask the dumb questions! :o

First...:thanks: for all your efforts to compile this and get it working.

I just downloaded Lord Mulder's latest exe, but when I try to have it convert a wave file from CMD using windows 7, I can't seem to get it to work. I have tried multiple wave files with the following usage:

dcaenc -i test.wav -o test.dts -b 1509

Every time I get the message:
"Could not open or parse "test.wav".
Error: Failed to open file!

I have been tracking Patrokov's work on this because I would ideally love to be able to take a 6 channel w64 audio track I have made and use DTS instead of Dolby Digital for blu-ray. Any thoughts?

[dj_doc]

geminigod try to pass your file through sox.

[geminigod]

I downloaded sox. Now I just need to figure out how to use it! Any advice on command line usage? What will take you a minute to explain will probably take me hours to figure out the proper syntax.

[LoRd_MuldeR]

Your syntax looks correct to me.

Error: Failed to open file!

This indicates the file could not be opened for reading at all. It failed before even "looking" at the file's content. Maybe the file is "blocked" by another app?

BTW: The Wave file reader in dcaenc doesn't support any "w64" files at all. This applies to most audio tools at this time...

(6 channel support in dcaenc should be working though, from normal RIFF/Wave files. You can even use "oversize" Wave/RIFF files with the "-l" option)

Any advice on command line usage?

Depends on what you want to do with SoX ;)

Usually the syntax is like "sox.exe [<infile options>] infile.wav [<outfile options>] outfile.wav [<filter_1> ... <filter_n>]"

For a simple sample rate conversion, for example, you'd use "sox.exe infile.wav -r 48000 outfile.wav" :)

[geminigod]

Thanks Lord Mulder! You were right. Once I closed my video editor that I rendered the wave file from, I was able to get dcaenc to read the file. Doh! Not sure why that was the case since it wasn't anything actively open in my editor and I had even moved the file around on my computer without problem.

Now I just need to figure out how to bypass the length restrictions on wave files to make a 6 channel wave file that is 7GB in size. (I thought that was the point of w64.) Maybe I can accomplish this with sox and convert the w64 to wav and then feed into dcaenc.

[Selur]

Now I just need to figure out how to bypass the length restrictions on wave files to make a 6 channel wave file that is 7GB in size.
decode with sox, pipe to dcenc and make sure you enable:
-l Ignore input length, can be useful when reading from stdin
source: dcaenc -h

[Midzuki]

(I thought that was the point of w64.)

And it still is :) The problem is, many/most applications simply don't support reading/writing W64 yet :(

[Midzuki]

@ Lord_Mulder --- a minor "cosmetic nitpick" :)

I think the following "output" should be improved :rolleyes:

[F:\XPERIMENTS\whatever]
=>dcaenc -v
dcaenc-1 [Jan 6 2012]

dcaenc-1
Compiled on Jan 6 2012 at 18:59:51 using GNU GCC 4.5
http://aepatrakov.narod.ru/dcaenc/

[F:\XPERIMENTS\whatever]
=>

[geminigod]

I think I've officially got a working workflow, though after re-reading through this thread I am still confused on the matter of byte swapping. Why and when should I be concerned about this? Patrokov kind of makes it sound like it always needs to be done, but i'm skeptical that is the case.

[Selur]

byte swapping changes between BE and LE encoding
LE is also in the DTS Standard but BE is better supported by decoders&Co -> stay with BE unless you know you need LE
(BE is default for LordMulders builts)

[Midzuki]

Never mind, I'd better just hexedit the binary --- and add an icon :devil: to it as well :cool:

@ Lord_Mulder --- a minor "cosmetic nitpick" :)

I think the following "output" should be improved :rolleyes:

[F:\XPERIMENTS\whatever]
=>dcaenc -v
dcaenc-1 [Jan 6 2012]

dcaenc-1
Compiled on Jan 6 2012 at 18:59:51 using GNU GCC 4.5
http://aepatrakov.narod.ru/dcaenc/

[F:\XPERIMENTS\whatever]
=>

[Midzuki]

As a side note: Is it just me or do LoRd_MuldeRs binary get smaller and smaller each time? (not that I'm complaining, it's just an observation)

Let's see...

compiled w/ MSYS+GCC: 348kB

compiled w/ ICL 12: 370kB

However Lord_Mulder applies UPX :devil: on his binary, so that it shrinks to 109kB :sly:

Anyway, I've just added a 32x32 icon to my build of dcaenc, and now it contains only 326kB :eek:

:cool:

[Midzuki]

To whom this may interest:

RENBRU5D.tar.gz @

https://skydrive.live.com/#cid=5ACF098E0EBAE8D5&id=5ACF098E0EBAE8D5!153

=>dcaenc

ERROR: Required arguments are missing.
Try 'dcaenc -h' for more information.



=>dcaenc -v

dcaenc-1
Compiled on Jan 12 2012 at 20:55:48 using GNU GCC 4.5.2
http://aepatrakov.narod.ru/dcaenc/
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc

Copyright (c) 2008-2011 Alexander E. Patrakov <patrakov@gmail.com>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.

=>dcaenc -h

DCAENC --- experimental 'Coherent Acoustics' compressor.

Usage: dcaenc -i <input.wav> -o <output.dts> -b <kbps>

Optional:
-l Ignore input length, can be useful when reading from stdin
-e Set the byte-order to 'Little-Endian' (default is 'Big-Endian')
-h Print this help screen
-v Show version info

DETAILS:

The input .WAV file must be either 16-bit or 32-bit integer;
the input or output file name can be "-" for stdin/stdout;
only the following channel-layouts are accepted:
mono, stereo, quadro, 5.0, 5.1.

The *actual* bitrate can be any value between 32 and 6144,
however both the minimum and the maximum values vary,
depending on the channel-layout and on the sample rate as well;
for DVD-Video, only the bitrates 754.5 and 1509.75 are compliant;
as for Blu-Ray, only the following values are generally regarded as compliant:
192, 255, 318, 384, 447, 510, 639, 754.5, 960, 1152, 1344, 1509.75.

* Valid sample rates (in kHz):

8 11.025 12 16 22.05 24 32 44.1 48

* Transmission bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 768
960 1024 1152 1280 1344 1408 1411.2 1472
1536 1920 2048 3072 3840 open VBR LOSSLESS

[geminigod]

To whom this may interest :)


* Valid bitrates (in kbps):

32 56 64 96 112 128 192 224
256 320 384 448 512 576 640 754.5
960 1024 1152 1280 1344 1408 1411.2 1472
1509 1920 2048 3072 3840 open VBR LOSSLESS

WARNING:
Currently not all possible combinations of frequencies and bitrates are supported.



I guess there is an argument to be made for posting the low bitrates with the WARNING caveat, but posting above 1509 is a bit misleading since I believe that even the official DTS codec doesn't support higher than that.:scared:

Maybe better to only list 754-1509 with with no caveat for now?? Just my two cents.

While you are at it, it might be good to list the supported bit depths of 16 and 32 (no 24) as well. I seem to recall something about an issue with 32 floating point also??

[Midzuki]

I guess there is an argument to be made for posting the low bitrates with the WARNING caveat, but posting above 1509 is a bit misleading since I believe that even the official DTS codec doesn't support higher than that.:scared:

As I had said,

1) According to the file ts_102114v010301p.pdf ("ETSI TS 102 114 V1.3.1 [2011-08]"), the «targeted bitrates» above 1536kbps, together with the types "VBR" and "lossless", have been declared `invalid´ :scared:

Well, the open-source encoder itself supports those "overkilling bitrates", and so far I have not found a dca decoder that doesn't support them... In fact, and in practice, the software decoders seemingly care not about the targeted bitrate, but yes about the "playback rate" (read: the sampling frequency).

Maybe better to only list 754-1509 with with no caveat for now?? Just my two cents.

:confused: :confused: :confused:

[geminigod]

Well, the open-source encoder itself supports those "overkilling bitrates", and so far I have not found a dca decoder that doesn't support them... In fact, and in practice, the software decoders seemingly care not about the targeted bitrate

Oh, I read your WARNING statement more carefully. I didn't realize that the lower bitrates were possible with lower sampling rates. I just knew that 754 was lowest with 48k. I also wasn't aware that encoder allowed for higher than 1509. :o

Listing supported bit depths still is a good idea though. :p

[Selur]

If someone was the time it would be nice to know what bit rate & frequency combinations are possible and which are allowed by the standard.

[Midzuki]

FWIW, the DTS-HD Encoder Suite lists the following bitrates (for 48kHz of course):

192, 255, 318, 384, 447, 510, 639, 754.5, 960, 1152, 1344, and 1509 kilobits-per-second ;

Listing supported bit depths still is a good idea though. :p

Already on the "TODO list" :)

[geminigod]

Well crud. SoX is failing me in rendering my w64 to wav to manipulate in dcaenc, as is every other program. I'm assuming this is due to the wav file size being over 4GB. Thoughts on how to get around this? Worst case scenario I could split the audio track to two pieces, but previous posts seem to imply that there is a way for me to get around having to do this.

On a probably unrelated note, SoX also is reporting the wrong length for w64 files. The actual length is 3:13 and SoX is reporting as 0:28. There was a known issue with 24 bit depth and length reporting that was supposedly fixed in latest version. So I re-rendered w64 to 16 bits and now SoX reports 1:09 length.

[Selur]

On a probably unrelated note, SoX also is reporting the wrong length for w64 files.
don't forget to report this to the SoX bug tracker (http://sourceforge.net/tracker/?group_id=10706&atid=110706) if it's not already in there.

[geminigod]

don't forget to report this to the SoX bug tracker (http://sourceforge.net/tracker/?group_id=10706&atid=110706) if it's not already in there.

Done.

[TFM_TheMask]

Is it possible to create a dll also instead of only an exe?

[LoRd_MuldeR]

Is it possible to create a dll also instead of only an exe?

Sure. The command-line front-end internally just calls the encoder library.

Though in the current Visual Studio solution, the front-end and the library are not in separate projects yet - for sake of simplicity.

Wouldn't be that hard to do though ;)

[TFM_TheMask]

Sure. The command-line front-end internally just calls the encoder library.

Though in the current Visual Studio solution, the front-end and the library are not in separate projects yet - for sake of simplicity.

Wouldn't be that hard to do though ;)

That is good to hear :cool:.

The only thing is that my C programming skills are limited and also compiling with Visual Studio (I'm more a Delphi guy). So if anyone has the skills and wants to create the dll version then I am here to test it if needed.

[Qaq]

Just made few 2.0 44/16 DTS: 1500-3000 kbps, with and without -e, packed into mka. Decoding seems no problem (no matter of -e is used or not) by LAV/Arcsoft, but I couldn't bitstream to avr no matter of splitter/decoder :devil:
ffdshow shows bitstream, but there are no sound and incoming indication in AVR. There is no problem with regular DTS-WAVs.

[Midzuki]

^ @ Qaq :

I suppose your AVR "expects" 44.1kHz DTS to have a very-specific bitrate (1411.2kbps).

[LoRd_MuldeR]

That is good to hear :cool:.

The only thing is that my C programming skills are limited and also compiling with Visual Studio (I'm more a Delphi guy). So if anyone has the skills and wants to create the dll version then I am here to test it if needed.

Okay, I moved the actual encoder "core" into a separate project within the MSVC solution. It is now linked into the CLI encoder as a static library.

I also added a third project to the solution, which builds dcaenc as a DLL file. The DLL is still untested though ;)

You should be able to call dcaenc from your application just like it is done in 'main.c' of the CLI encoder. But make sure to link against 'dcadll_vc2010_imp.lib' to use the DLL.

For Delphi you will have to create your own "header" (.pas) file with the required DLL imports. Shouldn't be too hard to translate 'dcaenc.h' to Delphi...

Details:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/3c700dccdc5d160623baae67922757cff6123bb4

[Qaq]

I suppose your AVR "expects" 44.1kHz DTS to have a very-specific bitrate (1411.2kbps).
Thats possible. The main goal is to get as close to a source (lossless) as possible. I'll see if I can do anything here. Strange that Arcsoft is not touchy at all about bitrates and endians.
I am not sure whether ffdshow or LAV Audio support "SPDIFing" other bitrates than 1509kbps or other channel layouts than 5.1
I tried ffdshow with 2.0 96/24 DTS MA. No problem.

[TFM_TheMask]

Okay, I moved the actual encoder "core" into a separate project within the MSVC solution. It is now linked into the CLI encoder as a static library.

I also added a third project to the solution, which builds dcaenc as a DLL file. The DLL is still untested though ;)

You should be able to call dcaenc from your application just like it is done in 'main.c' of the CLI encoder. But make sure to link against 'dcadll_vc2010_imp.lib' to use the DLL.

For Delphi you will have to create your own "header" (.pas) file with the required DLL imports. Shouldn't be too hard to translate 'dcaenc.h' to Delphi...

Details:
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/3c700dccdc5d160623baae67922757cff6123bb4

Thanks LoRd_MuldeR. Super. I will translate the header to pas for delphi.

[Kurtnoise]

To whom this may interest :)

what do you mean by open, VBR, Lossless ?

[LoRd_MuldeR]

I will translate the header to pas for delphi.

Feel free to post your result ;)

In the meantime, here is an updated DLL that has the dependency on MSVCR100.DLL removed.

(Now using the MSVCRT.DLL that is part of Windows)

Please use updated DLL with updated file name, as suggested by dcaenc original author.

[Midzuki]

what do you mean by open, VBR, Lossless ?

In the page 13 of the document "ETSI TS 102 114 V1.2.1 (2002-12)":

RATE specifies the targeted transmission data rate for the current frame of audio (see table 5.7). The open mode allows for bit rates not defined by the table. Variable and loss-less modes imply that the data rate changes from frame to frame.

Table 5.7: RATE parameter vs. targeted bit-rate

0b00000 32
0b00001 56
0b00010 64
0b00011 96
0b00100 112
0b00101 128
0b00110 192
0b00111 224
0b01000 256
0b01001 320
0b01010 384
0b01011 448
0b01100 512
0b01101 576
0b01110 640
0b01111 768
0b10000 960
0b10001 1 024
0b10010 1 152
0b10011 1 280
0b10100 1 344
0b10101 1 408
0b10110 1 411,2 (sic)
0b10111 1 472
0b11000 1 536
0b11001 1 920
0b11010 2 048
0b11011 3 072
0b11100 3 840
0b11101 open
0b11110 Variable
0b11111 Loss-less (sic)


See also:

http://wiki.multimedia.cx/index.php?title=DTS#Frame_format

[Midzuki]

Thats possible. The main goal is to get as close to a source (lossless) as possible. I'll see if I can do anything here. Strange that Arcsoft is not touchy at all about bitrates and endians.

Speaking in general, for 48kHz, 256kbps per (full-range) channel should sound "transparent" to most people's ears
( but YMMV of course :) )

...
Many people think/say 5.1 DTS @ 44.1kHz @ 1234.8kbps is [ place your favorite superlative here :) ]. However, that's mathemagically-equivalent to 1344kbps @ 48kHz. In other words, 1509kbps has been overkill since the very-beginning :p

Regarding Arcsoft, or even libavcodec, a software decoder is not required to save 1 cent per 100,000 manufactured units :rolleyes:

[TFM_TheMask]

Feel free to post your result ;)

In the meantime, here is an updated DLL that has the dependency on MSVCR100.DLL removed.

(Now using the MSVCRT.DLL that is part of Windows)

Please use updated DLL with updated file name, as suggested by dcaenc original author.

I will, only one question. How do I translate the following to Pascal? Should I just initialize a pointer?

typedef struct dcaenc_context_s *dcaenc_context;

[LoRd_MuldeR]

Yeah, I think the calling app doesn't need to know how the struct is defined internally - it might even change in future versions.

Just store the pointer you get when creating the dcaenc context and then pass it back into dcaenc when calling the dcaenc_convert_s32() function :)

[Midzuki]

...
48kHz 2 Channel works with: 320 384 448 512 576 640 (I would recommend 576 since at least my receiver doesn't like 640 ;))

Hummm, what about trying 639kbps ???

Because, if I set "-b 640", both eac3to and foobar2000 indicate an effective bitrate of 642kbps, and this might be the reason why your receiver didn't like it :confused:

Whereas if I choose "-b 639", eac3to says the effective bitrate really is 639kbps http://forum.doom9.org/images/icons/icon3.gif

(Possibly the firmware "expects" the actual bitrate is never greater than the targeted bitrate,
but this is just a wild guess of course)

[Kurtnoise]

In the page 13 of the document "ETSI TS 102 114 V1.2.1 (2002-12)":

So...what's the point ? these values are somewhere in the code or available through the interface ?

[Midzuki]

So...what's the point ? these values are somewhere in the code or available through the interface ?


Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

Short answer:

*yawns*

[geminigod]

Speaking in general, for 48kHz, 256kbps per (full-range) channel should sound "transparent" to most people's ears
( but YMMV of course :) )

I mostly agree with this. Under ideal listening conditions with the right song I could nitpick a bit higher maybe to 320 kbps before I lose the ability to discern between the lossy and lossless version.

The 48kHz is a big deal though in my opinion and an unfortunate problem with CD. Increasing bitrate may yield a mathematical equivalence between 44.1 & 48 but that doesn't mean there is a sonic equivalence (assuming it isn't an up-convert). I find there to be more value in sampling size than in each sample's description. Its like getting driving directions from somebody. Would you rather have very detailed directions but with a couple turns missing or simpler directions with a brief description of every turn? The number of letters used are mathematically equivalent.

I was just ripping some records today and contemplating the misconception that analogue lovers have about digital. Most of the richness that Vinyl collectors such as myself love has less to do with the digital format and more to do with dynamic range compression applied to digital in the mastering process.

[geminigod]

Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

Short answer:

*yawns*

Lol

:goodpost:

[Midzuki]

^
^

Bottom line is, you'd better "dca-encode" your CDDA-tracks and your vinyl rips @ either 639kbps or 754kbps. BTW, 640kbps is not the only "potentially-problematic" bitrate for dcaenc --- 1.0 + 44.1kHz @ 192kbps actually gives a 193kbps output :confused:

[Kurtnoise]

Long answer:

=>dcaenc -i input.wav -o output.dts -b vbr

ERROR: Bitrate must be between 32 and 6144 kbps!

Apparently dcaenc is less stupid than I thought :rolleyes:

So, vbr mode, open & lossless are not available...So, no need to specify this in the help.

[Midzuki]

So, vbr mode, open & lossless are not available...So, no need to specify this in the help.

No problem. Anyone can edit the main.c according to their personal preferences. Lord Mulder is surely a very-busy person, and I could not convince him that my ideas are better than his :p I am not forcing anyone to download or to use my MinGW builds of dcaenc. :)

[Selur]

here a bit about what the encoder accepts atm. (tested by try&error)

mono@8kHz 32-2048
mono@12kHz 48-3072
mono@16kHz 48-3842 (didn't check higher)
mono@22.05kHz 65-3842 (didn't check higher)
mono@24kHz 71-3842 (didn't check higher)
mono@32kHz 95-3842 (didn't check higher)
mono@44.1kHz 130-3842 (didn't check higher)
mono@48kHz 142-3842 (didn't check higher)

stereo@8kHz 96-2048
stereo@12kHz 96-3842 (didn't check higher)
stereo@16kHz 96-3842 (didn't check higher)
stereo@22.05kHz 128-3842 (didn't check higher)
stereo@24kHz 192-3842 (didn't check higher)
stereo@32kHz 192-3842 (didn't check higher)
stereo@44.1kHz 256-3842 (didn't check higher)
stereo@48kHz 271-3842 (didn't check higher)

5.1@8kHz 112-2048
5.1@12kHz 168-3072 (didn't check higher)
5.1@16kHz 224-3842 (didn't check higher)
5.1@22.05kHz 308-3842 (didn't check higher)
5.1@32kHz 447-3842 (didn't check higher)
5.1@44.1kHz 615-3842 (didn't check higher)
5.1@48kHz 670-3842 (didn't check higher)

Cu Selur

[geminigod]

Thanks Selur. That is very helpful.

[Midzuki]

@ Selur: many many :thanks: for being less lazy than I :o :D

P.S.: Ooops, I have already found 1 incorrection in your list :(

stereo@48kHz 271 — ???

@ Lord Mulder: couldn't those limits be calculated directly thru the dcaenc library and then conveniently output by a command-line switch ???

:confused: :confused: :confused:

+++++++++

P.P.S.: Definitely there should be an easier way than finding/creating 6 (channel layouts) x 9 (frequencies) = 54 .WAV files, and then trying every integer "kbps" between 32 and 6144 :scared: Even with the help from a well-crafted batch-file or script, that would not be quite sane :(

[LoRd_MuldeR]

Well, the CLI front-end simply tries to initialize the dcaenc library with the given parameters. That either fails or succeeds :scared:

Internally dcaenc_create() does a number of calculations to determine "frame_bits" and "min_frame_bits".

It then will fail if either "frame_bits < min_frame_bits" or "frame_bits > 131072" or "(flags & DCAENC_FLAG_IEC_WRAP) && frame_bits > 16320" evaluates to TRUE.

So what exactly do you want to output on the manpage? ;)

[Selur]

Ooops, I have already found 1 incorrection in your list

stereo@48kHz 271 — ???
damn,.. :/ fixed it,..

[geminigod]

Sigh... :(

Anyone care to compile a development version of SoX for me?? I have been coordinating with Uklauer privately and via the bug tracker regarding SoX's length reporting with w64 files.

His response:
Do you have a chance to compile and try a current development version from
the git repository? Your description is consistent with the file length
being reduced modulo 2^32, and this is supposed to be fixed now (after
14.3.2). If you can't try the development version, a 14.4.0 release
candidate will be out in about two weeks' time.

Here the calculations: actual file length in bytes for 16 bit:
3.22*3600*48000*6*2 = 6676992000, for 24 bit: 3.22*3600*48000*6*3 =
10015488000; back to time in hours, for 16 bit:
(6676992000%2^32)/2/6/48000/3600 = 1.15 (1h09m); for 24 bit:
(10015488000%2^32)/3/6/48000/3600 = 0.46 (0h27m).


Apparently he can't compile for windows and neither can I :(.

Info I shared with him on my project:



Here is a bit more feedback. I cannot seem to find a workaround on the
length issue. The --ignore-length command doesn't change the outcome at
all.

Using the following command line:

sox -V4 --ignore-length "large file test.w64" -t wavpcm - | dcaenc-DEBUG -i - -o "large file test.dts" -l
-b 1440


on a w64 file that is 16bit, 48kHz, 6 channels, & 3:13:49.076 (558 195 638
samples) in length, I get the following results:


dcaenc-1 [Jan 6 2012]
Copyright (c) 2008-2011 Alexander E. Patrakov <patrakov@gmail.com>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License
<http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.

Source: -
Output:large file test.dts
KBit/s: 1440

sox: SoX v14.3.2
time: Feb 27 2011 16:03:50
gcc: 4.5.0 20100414 (Fedora MinGW 4.5.0-1.fc14)
arch: 1248 48 44 L OMP
sox DBUG sndfile: `large file test.w64': Length : 2403380640
sox DBUG sndfile: `large file test.w64': riff : 6698347936 (should be
2403380640)
sox DBUG sndfile: `large file test.w64': wave
sox DBUG sndfile: `large file test.w64': fmt : 64
sox DBUG sndfile: `large file test.w64': Format : 0xFFFE =>
WAVE_FORMAT_EXTENSIBLE
sox DBUG sndfile: `large file test.w64': Channels : 6
sox DBUG sndfile: `large file test.w64': Sample Rate : 48000
sox DBUG sndfile: `large file test': Block Align : 12
sox DBUG sndfile: `large file test.w64': Bit Width : 16
sox DBUG sndfile: `large file test.w64': Bytes/sec : 576000
sox DBUG sndfile: `large file test.w64': Valid Bits : 16
sox DBUG sndfile: large file test.w64': Channel Mask : 0x3F
sox DBUG sndfile: `large file test.w64': Subformat
sox DBUG sndfile: `large file test.w64': esf_field1 : 0x1
sox DBUG sndfile: `large file test.w64': esf_field2 : 0x0
sox DBUG sndfile: `large file test.w64': esf_field3 : 0x10
sox DBUG sndfile: `large file test.w64': esf_field4 : 0x80 0x0 0x0 0xAA
0x0 0x38 0x9B 0x71
sox DBUG sndfile: `large file test.w64': format : pcm
sox DBUG sndfile: `large file test.w64': data : 6698347680
sox DBUG sndfile: `large file test.w64': *** Unknown chunk marker : 189194.
Exiting parser.

Input File : large file test.w64'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:09:32.54 = 200281709 samples ~ 312940 CDDA sectors
File Size : 6.70G
Bit Rate : 12.8M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no

sox DBUG wav: Writing Wave file: Microsoft PCM format, 6 channels, 48000
samp/sec
sox DBUG wav: 576000 byte/sec, 12 block align, 16 bits/samp

Output File : '-' (wav)
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:09:32.54 = 200281709 samples ~ 312940 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'

sox INFO sox: effects chain: input 48000Hz 6 channels 16 bits (multi)
sox INFO sox: effects chain: output 48000Hz 6 channels 16 bits (multi)
Encoding... 69:32 [100.0%]
Done.


The resulting outputted file is " " & 1:09:32.555 (200 282 624 samples) in
length.

Sorry for over-complicating a bit with the piping into another program, but
it is irrelevant. The problem is on the SoX end of things.

[LoRd_MuldeR]

Do I get this right? You try to pipe a 'w64' file into dcaenc? I don't think its Wave parser will be able to deal with that. It was written with plain RIFF/Wave files in mind and nothing else.

(The only thing that the "-l" option does is ignoring the length field of the "data" chunk, as that field may not contain a valid value, e.g. in case of reading from STDIN)

[geminigod]

Do I get this right? You try to pipe a 'w64' file into dcaenc? I don't think its Wave parser will be able to deal with that. It was written with plain RIFF/Wave files in mind and nothing else.

(The only thing that the "-l" option does is ignoring the length field of the "data" chunk, as that field may not contain a valid value, e.g. in case of reading from STDIN)


Well the command line I posted was attempting to have sox convert the w64 to wav and then pipe that into dcaenc and thereby hopefully get around the 4GB limit of doing two separate steps by first converting to wav. So dcaenc is reading from the STDIN.

It seemed like it worked except for the fact that sox has issues in general with w64. The resulting DTS was the same length as what sox thinks the w64 is.
[code]
> soxi "large file test.w64"

Input File : 'large file test.w64'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:09:32.54 = 200281709 samples ~ 312940 CDDA sectors
File Size : 6.70G
Bit Rate : 12.8M
Sample Encoding: 16-bit Signed Integer PCM
[code]

Actual length 3:13. This is a known problem with sox and w64 that is currently being worked on.

Thoughts? Recommendations for getting this huge w64 file to dts?

I know this is getting slightly off topic, but it is very relevant to dcaenc because many audio tracks will exceed the wav size limit.

[Midzuki]

^
Recommendations for getting this huge w64 file to dts?

If you're looking for a "one-line" solution, I'm afraid you won't find it anytime soon. So if I were you, I'd split that .W64 file into several mono .WAVs through eac3to, and then write an appropriate audio-only && multichannel Avisynth script, so that

.AVS -> wavi.exe -> dcaenc.exe

Hope this helps :o

P.S.: LAV Splitter supports the W64 container, thus maybe you don't need eac3to in this case ^.^ ;

[b66pak]

or you can pipe using eac3to....
_

[Midzuki]

^

But of course :stupid: :stupid: :stupid:

[Midzuki]

Back on the topic =^.^=

Oh well, that's what I get for not paying attention to the damn code and/or documentation -.-

Originally posted by wavfile.c

/* 7*/ "Unsupported number of channels (only 1, 2, 4, 5 and 6)",

Besides, as the Back-Center channel "does not exist" :rolleyes: for dcaenc,

even a "3/1" input.wav will result in a "2/2" output.dts :(

[Midzuki]

This is semi-OT and somewhat "late" :o , but also probably useful

( or interesting at least :) )

Lord Mulder apparently thought I had used a "git clone" of Patrakov's original code. Actually, I had used the tarball available on Patrakov's web site; that tarball was!/¿still is? "ready for configure" :cool:

Besides, Lord Mulder did appear to ignore that his own gitorious folder is able to generate a tarball for the people who don't want to use the git application --- however in this case, the content of the tarball is not different from the git clone :helpful:

[LoRd_MuldeR]

Well the command line I posted was attempting to have sox convert the w64 to wav and then pipe that into dcaenc and thereby hopefully get around the 4GB limit of doing two separate steps by first converting to wav. So dcaenc is reading from the STDIN.

I see. As long as SoX sends a valid Wave header (with valid "fmt" and "data" chunk) over the pipe this should work. You'll have to use the '-l' switch for dcaenc, of course.

[LoRd_MuldeR]

Back on the topic =^.^=

Oh well, that's what I get for not paying attention to the damn code and/or documentation -.-



Besides, as the Back-Center channel "does not exist" :rolleyes: for dcaenc,

even a "3/1" input.wav will result in a "2/2" output.dts :(

These are all channel configurations supported by dcaenc:
#define DCAENC_CHANNELS_MONO 0
#define DCAENC_CHANNELS_DUAL_MONO 1
#define DCAENC_CHANNELS_STEREO 2
#define DCAENC_CHANNELS_STEREO_SUMDIFF 3
#define DCAENC_CHANNELS_STEREO_TOTAL 4
#define DCAENC_CHANNELS_3FRONT 5
#define DCAENC_CHANNELS_2FRONT_1REAR 6
#define DCAENC_CHANNELS_3FRONT_1REAR 7
#define DCAENC_CHANNELS_2FRONT_2REAR 8
#define DCAENC_CHANNELS_3FRONT_2REAR 9
#define DCAENC_CHANNELS_4FRONT_2REAR 10
#define DCAENC_CHANNELS_3FRONT_2REAR_1OV 11
#define DCAENC_CHANNELS_3FRONT_3REAR 12
#define DCAENC_CHANNELS_5FRONT_2REAR 13
#define DCAENC_CHANNELS_4FRONT_4REAR 14
#define DCAENC_CHANNELS_5FRONT_3REAR 15

Though the CLI front-end currently uses a hardcoded "number of channels" to "channel configuration" mapping.

[nu774]

Anyone care to compile a development version of SoX for me??
Here you are...
http://www.mediafire.com/file/keige47mr6mo8dh/SoX.zip
Built with Visual Studio 2010, commit 6257b1b873d24ff2192d86f6efa4817eb433480c (Jan 11, 2012)
Sorry for not being static linked. Tons of Dlls.

[b66pak]

@nu774 thanks a lot...
_

[Midzuki]

These are all channel configurations supported by dcaenc:
#define DCAENC_CHANNELS_MONO 0
#define DCAENC_CHANNELS_DUAL_MONO 1
#define DCAENC_CHANNELS_STEREO 2
#define DCAENC_CHANNELS_STEREO_SUMDIFF 3
#define DCAENC_CHANNELS_STEREO_TOTAL 4
#define DCAENC_CHANNELS_3FRONT 5
#define DCAENC_CHANNELS_2FRONT_1REAR 6
#define DCAENC_CHANNELS_3FRONT_1REAR 7
#define DCAENC_CHANNELS_2FRONT_2REAR 8
#define DCAENC_CHANNELS_3FRONT_2REAR 9
#define DCAENC_CHANNELS_4FRONT_2REAR 10
#define DCAENC_CHANNELS_3FRONT_2REAR_1OV 11
#define DCAENC_CHANNELS_3FRONT_3REAR 12
#define DCAENC_CHANNELS_5FRONT_2REAR 13
#define DCAENC_CHANNELS_4FRONT_4REAR 14
#define DCAENC_CHANNELS_5FRONT_3REAR 15

Though the CLI front-end currently uses a hardcoded "number of channels" to "channel configuration" mapping.

Very well... That's the reason why I have added this text to main.c:

only the following channel-layouts are accepted:
mono, stereo, quadro, 5.0, 5.1.

besides, ( regarding the "bitrate hell" :p ):

The *actual* bitrate can be any value between 32 and 6144, BUT
the minimum and maximum values vary according to the frequency and the channel-layout;

I also modified the error message about "insufficient bitrate", because
5400kbps cannot be "insufficient" for a mono input @ 44.1kHz ;)

[LoRd_MuldeR]

Here is a new build that allows the user to overwrite the pre-selected channel configuration (see help for details). Updated DLL is included.

[Selur]

Nice,thanks !

[LoRd_MuldeR]

Build in previous post updated: Channel configuration will now be checked for compatibility with input Wave file. Also added switch to indicate presence of LFE channel.

If, for example, you want to create a typical "5.1" encode from a six channel Wave file, then use 3FRONT_2REAR ("-c 10") in conjunction with "-f" switch - this is the default for 6ch input.

You could even create a "Center-only with LFE" encode now from a two channel Wave file by using MONO ("-c 1") in conjunction with the "-f" switch, confirmed by MediaInfo.

[b66pak]

for this wav:

General
Complete name : audio.wav
Format : Wave
File size : 22.0 MiB
Duration : 40s 0ms
Overall bit rate mode : Constant
Overall bit rate : 4 608 Kbps

Audio
ID : 0
Format : PCM
Format settings, Endianness : Little
Codec ID : 1
Duration : 40s 0ms
Bit rate mode : Constant
Bit rate : 4 608 Kbps
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 22.0 MiB (100%)

with dcaenc.2012-01-12.R2:

dcaenc -i audio.wav -o audio.dts -b 1509

or

dcaenc -i audio.wav -o audio.dts -b 1509 -c 10 -f


i get:

Invalid channel configuration for input audio!


with dcaenc.2012-01-02 is OK...
_

[Selur]

I agree something seems to be broken:
ffmpeg -threads 8 -v -10 -y -i "D:\Encoding Output\test_20_39_06_59101.ac3" -ac 6 -acodec pcm_s16le -f wav - | dcaenc -i - -o "D:\Encoding Output\test_20_39_06_59102.dts" -b 754 -l
and
ffmpeg -threads 8 -v -10 -y -i "D:\Encoding Output\test_20_39_06_59101.ac3" -ac 6 -acodec pcm_s16le -f wav - | dcaenc -i - -o "D:\Encoding Output\test_20_39_06_59102.dts" -b 754 -c 10 -f -l
both give me:
Invalid channel configuration for input audio!

Cu Selur

Ps.: works for stereo sources

[LoRd_MuldeR]

There was a little syntax error in my channel configuration checking code. Thus valid configurations could be rejected. Should be fixed now :o

New build is available now

[Selur]

New build seems to work. :)

Cu Selur

[geminigod]

Has anyone compared the surcode DTS codec to dcaenc to see what the actual differences are? Aside from Surcode costing $250 of course. :) Just curious...

[geminigod]

Here is a new build that allows the user to overwrite the pre-selected channel configuration (see help for details). Updated DLL is included.

How hard would it be to make it possible for dcaenc to combine 6 mono wav files into one 6 channel dts file?

[LoRd_MuldeR]

How hard would it be to make it possible for dcaenc to combine 6 mono wav files into one 6 channel dts file?

It would need quite a lot of changes and I'm not planning to add that feature at the moment. Sorry.

[geminigod]

It would need quite a lot of changes and I'm not planning to add that feature at the moment. Sorry.

No worries. Just thought I would ask. It would make this app much easier to use, but I will figure out a workaround.

[Midzuki]

Originally posted by Lord Mulder http://forum.doom9.org/images/buttons/lastpost.gif (http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/94bafb73b38ade69ef7538c92be5ad867c8b0bfc#comment_81760)

Added option to overwrite auto-selected channel mode. Also improved the help-screen (thanks to 'Selur' for testing all the bitrate/channel/samplerate combinations)

1) Certainly Selur's job is much better than mine :o , no doubt about this, however his list is far from complete :( The frequencies 11.025kHz and 24kHz are missing, not to mention the channel-layouts with 3 and 4 channels ;)

2) dcaenc was not designed to deal correctly with the Wave-Format-Extensible channel masks (especifically, the Back-Center one). Is that EASILY fixable? :confused:

No problemos if the answer is "no" :)

[Selur]

regarding 3 channel: -> "Error: Unsupported number of channels (only 1, 2, 4, 5 and 6)"
regarding 24kHz: -> forgot 24kHz only for 5.1 ;) -> 5.1@24kHz 335-3842 (didn't check higher)
regarding: 11.025kHz totally overlooked it :)

mono@8kHz 32-2048
mono@11.025kHz 33-2822
mono@12kHz 48-3072
mono@16kHz 48-3842 (didn't check higher)
mono@22.05kHz 65-3842 (didn't check higher)
mono@24kHz 71-3842 (didn't check higher)
mono@32kHz 95-3842 (didn't check higher)
mono@44.1kHz 130-3842 (didn't check higher)
mono@48kHz 142-3842 (didn't check higher)

stereo@8kHz 96-2048
stereo@11.025kHz 63-2822
stereo@12kHz 96-3842 (didn't check higher)
stereo@16kHz 96-3842 (didn't check higher)
stereo@22.05kHz 128-3842 (didn't check higher)
stereo@24kHz 192-3842 (didn't check higher)
stereo@32kHz 192-3842 (didn't check higher)
stereo@44.1kHz 256-3842 (didn't check higher)
stereo@48kHz 271-3842 (didn't check higher)

4.0@8kHz 89-2048
4.0@11.025kHz 122-2822
4.0@12kHz 133-3072
4.0@16kHz 178-3842 (didn't check higher)
4.0@22.05kHz 244-3842 (didn't check higher)
4.0@24kHz 266-3842 (didn't check higher)
4.0@32kHz 356-3842 (didn't check higher)
4.0@44.1kHz 488-3842 (didn't check higher)
4.0@48kHz 532-3842 (didn't check higher)

4.1@8kHz 111-2048
4.1@11.025kHz 153-2822
4.1@12kHz 166-3072
4.1@16kHz 222-3842 (didn't check higher)
4.1@22.05kHz 305-3842 (didn't check higher)
4.1@24kHz 332-3842 (didn't check higher)
4.1@32kHz 443-3842 (didn't check higher)
4.1@44.1kHz 610-3842 (didn't check higher)
4.1@48kHz 664-3842 (didn't check higher)

5.1@8kHz 112-2048
5.1@11.025kHz 154-2822
5.1@12kHz 168-3072 (didn't check higher)
5.1@16kHz 224-3842 (didn't check higher)
5.1@22.05kHz 308-3842 (didn't check higher)
5.1@24kHz 335-3842 (didn't check higher)
5.1@32kHz 447-3842 (didn't check higher)
5.1@44.1kHz 615-3842 (didn't check higher)
5.1@48kHz 670-3842 (didn't check higher)

[LoRd_MuldeR]

regarding 3 channel: -> "Error: Unsupported number of channels (only 1, 2, 4, 5 and 6)"

Yes, it's not supported.

If it turns out that this is only a limitation of the Wave reader, I can fix it (easily).

But if it's a limitation of the actual encoder, I probably can't do anything...

[amtm]

Has anyone compared the surcode DTS codec to dcaenc to see what the actual differences are? Aside from Surcode costing $250 of course. :) Just curious...

The major differences would be that it supports all the extended DTS formats (DTS-ES, DTS-HD HR, DTS-HD MA, the 96/24 extensions, etc.) and additional channel mappings that dcaenc doesn't. In my tests it's also more optimized and probably has more advanced psychoacoustic enhancements in it as well. It's also unusable for making silence frames for extracted DTS-HD cores since the frame size of dcaenc output matches that of DVD DTS and so outside of libavcodec your DTS track won't decode (this is why dcaenc can't be used to fix delaycut's issues with Blu-Ray DTS tracks).

[Midzuki]

If it turns out that this is only a limitation of the Wave reader, I can fix it (easily).

That's good-news :cool: :)

But if it's a limitation of the actual encoder, I probably can't do anything...

At least you still can http://forum.videohelp.com/attachments/2671-1279232225/uglylol.gifPatrakov :)

[LoRd_MuldeR]

Hacked in support for 3 channel Wave files. Also added Delphi bindings (including a simplistic example).

Newer build can be found here:
http://forum.doom9.org/showthread.php?p=1570689#post1570689

[Selur]

Nice!
3.0@8kHz 68-2048
3.0@11.025kHz 93-2822
3.0@12kHz 101-3072
3.0@16kHz 135-3842 (didn't check higher)
3.0@22.05kHz 185-3842 (didn't check higher)
3.0@24kHz 202-3842 (didn't check higher)
3.0@32kHz 269-3842 (didn't check higher)
3.0@44.1kHz 370-3842 (didn't check higher)
3.0@48kHz 403-3842 (didn't check higher)

Cu Selur

[Midzuki]

3.0 WAV --> 3.0 dts = OK :)

3.0 WAV --> 2/1 dts = OK :)

2.1 WAV --> 2.1 dts = FAIL :(
(LFE channel = silent)

3.1 WAV --> 3.1 dts = FAIL :(
(idem)

[LoRd_MuldeR]

2.1 WAV --> 2.1 dts = FAIL :(
(LFE channel = silent)

Did you use "-c 3 -f", i.e. DCAENC_CHANNELS_STEREO + DCAENC_FLAG_LFE, when encoding this?

The default for 3ch input is DCAENC_CHANNELS_3FRONT now.

[Midzuki]

Did you use "-c 3 -f", i.e. DCAENC_CHANNELS_STEREO + DCAENC_FLAG_LFE, when encoding this?

Yes. No difference between your latest ICL12 build and my GCC build from some hours ago.

[Midzuki]

Please forget what I said about the 2.1 .DTSs --- there was some kind of conflict between LAV Audio and the Audigy drivers :confused: but now that's all solved ( or at least it seems so :o ). I checked with foobar2000, and the 2.1 DTS appeared to be correct since the very beginning :o

BUT :devil: --- regarding the 3.1 DTS streams, the Front-Right and the Front-Center channels are swapped by dcaenc

:confused: :confused: :confused:

[LoRd_MuldeR]

It's probably because the Wave reader currently knows nothing about the channel configuration ;)

The ultimate solution will be to forward the selected channel configuration into the Wave reader too (not only into the encoder lib), so channel re-ordering can be done correctly.

Actually the Wave reader does some re-ordering already, but that was probably written with the default channel configuration in mind.

And even if we do it correctly, we still need to trust on the Wave file to have the channels ordered properly according to the Wave specifications for multi-channel files...

[Midzuki]

Thanks for the explanation.

Now, a pseudo-random thought:

IF Patrakov happens to read the post above, hopefully he will understand that the commercial multichannel encoders accept multiple MONO inputs because of a very-good reason :rolleyes: :p

[b66pak]

you can use sox to pipe mono files:

sox -M FL.wav FR.wav FC.wav LFE.wav SL.wav SR.wav -t wavpcm - | dcaenc -i - -o 5.1.dts -b 1509 -l
_

[Midzuki]

^ Have you tried to create a 3.1 DTS in this way?

I have always fed dcaenc with proper multichannel .WAVs, in this particular case I doubt the intermediation by sox can make any difference...

[b66pak]

use this:

sox 3.1.wav -t wavpcm - remix 3 1 2 4 | dcaenc -i - -o 3.1.dts -b 1509 -l -c 6 -f
_

L.E.

you can also force it to 5.1 (SL & SR will be empty)

sox 3.1.wav -t wavpcm - remix 1 2 3 4 0 0 | dcaenc -i - -o 5.1.dts -b 1509 -l

[geminigod]

you can use sox to pipe mono files:

sox -M FL.wav FR.wav FC.wav LFE.wav SL.wav SR.wav -t wavpcm - | dcaenc -i - -o 5.1.dts -b 1509 -l
_

Nice. This might be an alternative solution for me, though I still haven't decided between dcaenc and surcode. I will have to do a test output from both to compare. One nice thing about surcode is that it will take a 24 bit input.

[LoRd_MuldeR]

With SoX, you can simply add "-b 16" or "-b 32" to do the required conversion.

[tebasuna51]

I think dcaenc must read the channels mask present in WAVE_FORMAT_EXTENSIBLE header to select/reject the channel configurations supported.

Is easy, first a new wavfile.h with:
typedef struct {
FILE * file;
unsigned int channels;
unsigned int bits_per_sample;
unsigned int sample_rate;
unsigned int samples_left;
unsigned int channel_mask;
} wavfile;

And in wavfile.c add:
/* wFormatTag */
result->channel_mask = 0; // unknow, then apply defaults s/channels

v = (uint32_t)fmt[0] | ((uint32_t)fmt[1] << 8);
if (v == 0xfffe)
{
result->channel_mask = (uint32_t)fmt[20] | ((uint32_t)fmt[21] << 8)
| ((uint32_t)fmt[22] << 16) | ((uint32_t)fmt[23] << 24);
v = (uint32_t)fmt[24] | ((uint32_t)fmt[25] << 8);
}

if (v != 1)
{
*error_msg = g_error_msg[6];
goto err3;
}

/* wChannels */

We can add also support for W64/RF64 files but now:
unsigned int samples_left;
must be unsigned int 64 bits;

I can suggest the code if you want.

[Midzuki]

@ tebasuna51:

:goodpost: and :thanks:

And just as a reminder :)

Speaker Position Decimal Value
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯
BACK_CENTER 256

FRONT_LEFT 1
FRONT_RIGHT 2
FRONT_CENTER 4
LOW_FREQUENCY 8
BACK_LEFT 16
BACK_RIGHT 32

[Midzuki]

Nice. This might be an alternative solution for me, though I still haven't decided between dcaenc and surcode. I will have to do a test output from both to compare. One nice thing about surcode is that it will take a 24 bit input.

If I were you, I'd use dcaenc for doing only what the commercial encoders cannot do. It's nice to know that now we have 9 sample rates to choose from, and I myself wasn't aware that the *actual* bitrates could be VERY different from the "official" bitrates. :stupid:

[tebasuna51]

And just as a reminder :)...

With less than 7 channels the:

SPEAKER_SIDE_LEFT 512 0x200
SPEAKER_SIDE_RIGHT 1024 0x400

can be used like BACK channels.

For instance eac3to output 1551 (0x60F) like channel-mask for 5.1 using SIDE speakers, but Faad, and others, output 63 (0x3F) for 5.1 using BACK speakers.

Now M$ prefer 0x60F for 5.1, but accept also 0x3F.

[Midzuki]

...
For instance eac3to output 1551 (0x60F) like channel-mask for 5.1 using SIDE speakers,

Hummm, now I understand why MediaInfo reports the Back-Center as a "side-channel".

:thanks: for the clarification.

[tebasuna51]

A table without not supported (by channel mask) or useless configurations supported by dcaenc:
config. supported by dcaenc dv Channel mask accepted
-------------------------------- -- ---------------------------------------
DCAENC_CHANNELS_MONO 0 any with mono channel
DCAENC_CHANNELS_STEREO 2 0x0003 or any stereo, 0x000B +LFE
DCAENC_CHANNELS_3FRONT 5 0x0007 (FL,FR,FC), 0x000F +LFE
DCAENC_CHANNELS_2FRONT_1REAR 6 0x0103 (FL,FR,BC), 0x010B +LFE
DCAENC_CHANNELS_3FRONT_1REAR 7 0x0107 (FL,FR,FC,BC), 0x010F +LFE
DCAENC_CHANNELS_2FRONT_2REAR 8 0x0033 (FL,FR,BL,BR), 0x003B +LFE or
0x0603 (FL,FR,SL,SR), 0x060B +LFE
DCAENC_CHANNELS_3FRONT_2REAR 9 0x0037 (FL,FR,FC,BL,BR), 0x003F +LFE or
0x0607 (FL,FR,FC,SL,SR), 0x060F +LFE

[LoRd_MuldeR]

I think dcaenc must read the channels mask present in WAVE_FORMAT_EXTENSIBLE header to select/reject the channel configurations supported.

While it would be good to support this feature, we cannot rely on it. Not all multi-channle Wave files have a WAVE_FORMAT_EXTENSIBLE header...

[amtm]

Nice. This might be an alternative solution for me, though I still haven't decided between dcaenc and surcode. I will have to do a test output from both to compare. One nice thing about surcode is that it will take a 24 bit input.

If you only care about encoding DTS for DVD then dcaenc should be perfectly fine for you. The benefits of a Surcode or the DTS Master Audio Suite is the fact that they do all the extra things I listed on the page back. Plus their GUIs are nice with built-in support for mono wav files and no need to dick around with SoX to pipe in input. It's up to you if $250 for Surcode, plus $250 if you want the Surcode for DTS-HD plugin for extended format encoding, is worth it. The only thing that Surcode is limited to with that plugin is that it can only do 6.1 encoding due to a limitation of Apple Compressor in Final Cut. On the other hand, DTS Master Audio Suite does the full gamut up to 7.1 but it's $1500.

[geminigod]

What I have is the surcode DTS DVD encoder. In test comparisons thus far with dcaenc I am not convinced that there is any psychoacoustic differences I can detect that this surcode encoder has over dcaenc. Both encoders were fed 6 mono wav files @ 48kHz. An old receiver of mine recognized both files as DTS and decoded them just fine.

The fact that dcaenc doesn't support 24 bit input really doesn't matter since it does support 32 bit. Thus it becomes just a simple matter of upscaling the bitrate in sox before piping to dcaenc.

One argument in favor of dcaenc is a rather strange anomaly that occurred with surecode. My dcaenc dts file and ac3 file are an identical duration of 3:13:49:088 (558,196,224 samples). The surecode dts file is 3:13:49:077 (558,195,712 samples). It isn't enough of a difference for it to matter to a viewer, but I am mildly curious why surecode's length is slightly off. Any thoughts on this discrepancy?

FYI for those like me who need to work with large audio files that exceed the 4GB limit, the command line I used is as follows (ignore the bit depth conversion part unless your bit depth of the input wav files is 24 bit:
sox -M "left.wav" "right.wav" "center.wav" "LFE.wav" "left surround.wav" "right surround.wav" -t wavpcm -b 32 - | dcaenc -i - -o "output.dts" -b 1509 -l

Sox effects could also probably be thrown into the same command line, but I did all of that earlier before I rendered my mono waves.

[amtm]

As I said it was only a "probably", but it's highly unlikely the output will be very different especially at the bitrate you specified since you are at the level of what is pretty much transparent with lossy DTS. You might notice it more if your bitrate was at 756kbit or below. As to the file size difference, I can't see any reason why they'd be different. When I get home in a couple of hours, I can do some test encodes with Surcode and Master Audio Suite and see if both consistently do it and compare bitstreams against what dcaenc does. Would it at all be possible for you to post the streams you got from Surcode and dcaenc on multiupload or something so I could also check them? There may be some hints in the bitstream for the discrepancy.

[geminigod]

Would it at all be possible for you to post the streams you got from Surcode and dcaenc on multiupload or something so I could also check them? There may be some hints in the bitstream for the discrepancy.

Sorry, just reading this. I already deleted the surcode version that I decided not to use. I'm sure you could rip the audio from a long movie that you own though and attempt to repeat the experiment.

[madhatter300871]

Has anybody compiled Mulders dtsenc ? If so, could they upload a copy ?

I have tried to compile it but to be totally honest my compiling skills are limited !! I have compiled with mingw before using ./configure ./make and make install but anything further than that and I am just way out of my comfort zone. I have no idea at all how to install autoconf and M4 and whatever else I am being asked for, Linux really isn't my bag and in all honesty I haven't got a bloody clue what I'm doing !!

Would love to have a play with this if anyone can help.

Thanks.

[madhatter300871]

Done it !!!! How happy am I !!!!

I had to install autoreconf, automake and libtool then i just compiled as per the instructions .....

[LoRd_MuldeR]

Has anybody compiled Mulders dtsenc ? If so, could they upload a copy ?

I provided pre-compiled binaries all the time. So if you just need a "working" binary, you can simply grab (http://forum.doom9.org/showthread.php?p=1551512#post1551512) the one I provided ;)

If you want to compile yourself and if you use my branch, you can use the provided VS2010 project file. Should compile through "out of the box".

(You would only need to deal with "autoreconf" or "automake", if you use the MinGW/MSYS tool chain)

[madhatter300871]

Lord_Mulder

Thanks for the reply, I didn't see your pre-compiled version ! If only I had looked properly.

As it happens I did eventually compile your branch using Mingw/Msys. If nothing else it was a process in educating myself more regarding mingw compiling so not a total waste of time.

On a side note, and I know the real answer to this is rtfm, but would you be so kind as to tell me if there are any command line switches available that are not printed to console with command dcaenc -h ?

Thanks.

[LoRd_MuldeR]

On a side note, and I know the real answer to this is rtfm, but would you be so kind as to tell me if there are any command line switches available that are not printed to console with command dcaenc -h ?

Look at "main.c" ;)

t = xgetopt(argc, argv, "i:o:b:c:fhlev", &opt)

If anything was missing in the help, that would be unintentionally.

[madhatter300871]

Thanks for that pointer, unfortunately I am totally unfamiliar with C code and have to confess to being nothing more than a VB programmer, making my own GUIs for all these wonderful command line tools. I know, I know, I know ..... the world hates VB !

I actually don't think anything is missing, I was just wondering.

I have made my first encode, piping an avisynth script into dcaenc with bepipe and I must say the DTS soundtrack sounds fantastic when passed through to my amp.

One more question, I think I have missed the point about setting the bitrate as when I set anything between 650 and 764 (this is the only range I have played with so far) my final DTS track is always 755Kb/s, am I doing something wrong ?

[LoRd_MuldeR]

The bitrate that is sent to the "dcaenc" library internally is an approximate bitrate.

Although, as far as I know, dcaenc currently only uses a constant bitrate, it seems there is no function to query the actual bitrate...

[madhatter300871]

Ahh, ok. Dont understand why it is an approximation but, as I have confessed, I am not an expert in these things.

To transmit DTS over SPDIF doesn't it have to match the PCM bitrate, which for a 48Khz track is 1536mb/s. Do I need to worry about this or does the audio renderer (or decoder) take care of this by padding it automatically ?

[Midzuki]

...
One more question, I think I have missed the point about setting the bitrate as when I set anything between 650 and 764 (this is the only range I have played with so far) my final DTS track is always 755Kb/s, am I doing something wrong ?

MediaInfo and other tools / players display only the "target bitrate" according to what is written in the frame headers. The *actual* bitrate is a different story:

...

Exact bitrate must be calculated with Samplerate, Number of PCM Sample Blocks and Primary Frame Byte Size. Here:

Bitrate = 8 x 2012 x 48000 / 512 = 1509000 bits/s = 1509 Kb/s

This is the bitrate when commercial encoders output compact DTS (.cpt), when output padded DTS (.dts) the frames are incremented with bytes '0' until reach Transmission Bit Rate.
Here add 36 '0' at the end of the 2012 frame to reach 1536 Kb/s.

[madhatter300871]

Do you know why the specified target bitrate isn't used, why it is only an approximation (just for my own understanding and interest).

When I playback, does the decoder/renderer take care of padding it as needed ?

[LoRd_MuldeR]

Do you know why the specified target bitrate isn't used, why it is only an approximation (just for my own understanding and interest).

I'm not an expert on DTS bitstream, but if the situation is somewhat similar to MP3, then the encoder can choose between several pre-defined frame sizes. So if you do constant bitrate encoding, i.e. always pick the same frame size, then each of the pre-defined frame sizes results in a specific bitrate. In MP3, for example, there is one pre-defined frame size for 128 kbps, one pre-defined frame size for 192 kbps and so on. You can't get any other "constant" bitrates than those. If, instead, you do variable bitrate encoding, i.e. mix different frame sizes in the same file, you can get any average(!) bitrate that you like - simply by varying the frame sizes accordingly. But as said before, I think dcaenc does not offer variable bitrate encoding yet. Is that possible with DTS at all?

[amtm]

Do you know why the specified target bitrate isn't used, why it is only an approximation (just for my own understanding and interest).

When I playback, does the decoder/renderer take care of padding it as needed ?

Because the DTS spec only allows certain bitrate values. dcaenc allows you to pass it an arbitrary value but then based off of that it selects one of the allowed values.

[madhatter300871]

Ahh, OK. So what are those bitrates that the DTS spec allows ? I thought 768 and 1536 where allowed values (for example). They are the most common ones I see on my movies with a DTS soundtrack.

Yet when I select 768 as a bitrate, mediainfo shows it as 755. Eac3to, on the other hand, shows 768 as the bitrate if i set anything between 670 up to about 780.

I'm just playing at the moment and have included DTS encoding in my app, just curious why the bitrates are off seeing as (we think) dcaenc only allows for CBR encoding.

[Midzuki]

^ Yet when I select 768 as a bitrate, mediainfo shows it as 755. Eac3to, on the other hand, shows 768 as the bitrate if i set anything between 670 up to about 780.

Are you encoding 5.1 sources only ??? :confused:

In case of doubt, (re-)read this thread (http://forum.doom9.org/showthread.php?t=163526) again and again. :)

[madhatter300871]

I am encoding 5.1 sources only. Do you know the DTS bitrates that the spec allows ?

[madhatter300871]

I re-read the post and found the answer, in fact I found the answer many times over ..... perhaps in future I should be more patient in trying to find an answer before posting a question !

Thanks.

[madhatter300871]

I am only interested in 754.5 and 1509 at the moment, I have a question. Is 1509 correct or should i specify 1509.75 ?

[Midzuki]

I am only interested in 754.5 and 1509 at the moment, I have a question. Is 1509 correct or should i specify 1509.75 ?

According to http://aepatrakov.narod.ru/dcaenc/command_line_encoder/ :

dcaenc input.wav output.dts 1509000

However you really should try both 1509 and 1509.75 kbps, then run LeeAudBi and check whether dcaenc outputs the same bitrate in both cases, or not. Also, IF the goal is DVD-authoring, test both streams in the authoring program.
Otherwise, you might also verify if lower bitrates such as 1344 or 1152 kbps are acceptable to your ears --- today disk space is cheap, but hey :)

[madhatter300871]

Disk space is cheap so space usage is not an issue for me really. I am not authoring DVDs but it would be nice to know that if I chose to, the bitrate would be accepted (I'll check it is accepted by the authoring program).

My main concern is that it is an acceptable bitrate for my amp. I know .. encode and check ! ... but it's good to throw these questions out.

I'll use LeeAudBi to check the output using different bitrates with dcaenc, never used that tool before but I have just downloaded it and will check it out, thanks for the pointer.

On a side note .... is MediaInfo not that accurate when checking audio bitrate ?

[Selur]

Is 1509 correct or should i specify 1509.75 ?
I normally use 1510 and it worked fine so far,.. :)
If anyone does some additional testing please share your findings!

Cu Selur

[madhatter300871]

Made a quick test.

Input was a 1536kbs, 5.1, 48KHz, DTS track.

Encoded with dcaenc at bitrates of 1141, 1411.2, 1509, 1509.75, 1510.

1141 is a random value just to see what happens.

@1141kbps LeeAudBi shows as 1152, mediainfo shows as 1152
@1411kbps LeeAudBi shows as 1411.2, mediainfo shows as 1411.2
@1509kbps LeeAudBi shows as 1536, mediainfo shows as 1510
@1509.75kbps LeeAudBi shows as 1536, mediainfo shows as 1510
@1510kbps LeeAudBi shows as 1536, mediainfo shows as 1510

Checking the source file, LeeAudBi shows as 1536, mediainfo shows as 1510.

[Midzuki]

Made a quick test.

Input was a 1536kbs, 5.1, 48KHz, DTS track.

Encoded with dcaenc at bitrates of 1141, 1411.2, 1509, 1509.75, 1510.

1141 is a random value just to see what happens.

@1141kbps LeeAudBi shows as 1152, mediainfo shows as 1152
@1411kbps LeeAudBi shows as 1411.2, mediainfo shows as 1411.2
@1509kbps LeeAudBi shows as 1536, mediainfo shows as 1510
@1509.75kbps LeeAudBi shows as 1536, mediainfo shows as 1510
@1510kbps LeeAudBi shows as 1536, mediainfo shows as 1510

Checking the source file, LeeAudBi shows as 1536, mediainfo shows as 1510.

Sadly I forgot to mention, LeeAudBi MUST be used together with a calculator :)

As tebasuna51 said:

Exact bitrate must be calculated with Samplerate, Number of PCM Sample Blocks and Primary Frame Byte Size.

Next time please buy some bottles of ATTENTION @ the drugstore next-corner :D

P.S.: eac3to would be a better option. ;)

[tebasuna51]

...
Checking the source file, LeeAudBi shows as 1536, mediainfo shows as 1510.

Yes, LeeAudBi only read the fields in DTS header and Transmission Bit Rate show always 1536 for 1509 or 1509.75 exact bitrate.

[madhatter300871]

OK, so mediainfo is correct ?

Is the 1510kbps (or whatever) stream padded to 1536 when it is decoded ?

[tebasuna51]

Not when is decoded, but when is sended through SPDIF.
Read http://ac3filter.net/forum/index.php?topic=10.0

[madhatter300871]

Ahh, yes. I remember now. Its the sending of DTS audio over SPDIF that means audio stream needs to be padded to meet the exact bitrate if PCM. Thanks for jogging my memory.

So, just for my own clarity, DTS audio can be any legal bitrate we want, it will automatically be padded (if needed) when sending over SPDIF.

I must say in all sincerity, aren't forums just great. I have no idea how I would self teach myself without them and the ability to tap into the knowledge of all you guys.

[geminigod]

Nice link Tebasuna.

Question 1: I am still confused though as to what the exact differences are between the "wrapped & padded" DTS vs. the just "padded" DTS.

Question 2: Why do so many places say spec for DTS is 1509 even though it just pads it up to 1536 anyway? Why not just encode at 1536? There must be a reason for undershooting this number a little bit??

Question 3: Tesabuna, you mentioned a while back that it wouldn't be too hard to add w64 support to this? I think that would be a nice feature for many who might be too intimidated by the work-around of piping split wav channels through SoX.

[Selur]

@geminigod: better open another thread for that, since it's not really dcaenc related,...

[b66pak]

Question 3: Tesabuna, you mentioned a while back that it wouldn't be too hard to add w64 support to this? I think that would be a nice feature for many who might be too intimidated by the work-around of piping split wav channels through SoX.

use this:

eac3to audio.w64 stdout.wav -down16 | dcaenc -i - -o audio.dts -l -b 1509

_

[geminigod]

@ Selur: What I wrote is most definitely dcaenc related. Not sure why you would say otherwise.

@b66pak: Thanks for taking the time to suggest SoX command line advice, but also doesn't really answer my questions. I am pretty familiar with SoX, so let me respond to that code quickly for the benefit of others. First, it is pointless to down-sample it to 16 when you can upsample to 32 bit and still be compatible with dcaenc. 2nd, up until the latest release, SoX didn't work properly with w64. I provided developer Uklauer feedback regarding getting this issue resolved. Since the latest release, there is a good chance that code will work, but I can just as easily mix and pipe 6 mono wav files. Long story short, I wasn't really inquiring about w64 for my sake but more for the sake of other less tech savvy film editors.

[Selur]

for me your posts are more related to the general format specifications of dts and the usage of sox than to dcaenc itself

[Midzuki]

I was bored :) , so I decided to compile dcaenc-2

( not sure if it was worth the effort though... :o :p )

[LoRd_MuldeR]

Just for the notes: Ported back the latest changes in 'dcaenc' to my branch and bumped version to 2.
http://gitorious.org/~mulder/dtsenc/mulders-dtsenc/commit/f7c5f87a2419dde43bacd595861b5de17a8677f6

(Only relevant change seems to be "Fixed buffer overflow on attempts to encode a 7.1 file" though)

[Midzuki]

While it would be good to support this feature, we cannot rely on it.

Not all multi-channle Wave files have a WAVE_FORMAT_EXTENSIBLE header...

Even though they should. :-/

Honestly, I do not see the point of still supporting broken/non-compliant files :( IMNSHO, .WAVS with more than two channels but without the WFEXT-flag should be completely rejected (together with the weird mono and stereo .WAVs that have it). Of course, firstly Patrakov himself should have realized that it was a bad idea to repeat certain mistakes of the FLAC format in its DCA encoder. -.-

[LoRd_MuldeR]

Okay, enough is enough. I moved the off-topic discussion. Let's stay on topic again.

[Selur]

can't compile the latest version on MAC
calling:
git clone git://gitorious.org/dtsenc/dtsenc.git
cd dtsenc
aclocal
autoconf -f -i -v

I get the following output:
autoconf: running /opt/local/bin/autom4te -f --melt -v --language=autoconf --output=configure configure.ac
autom4te: the trace request object is:
autom4te: $VAR1 = bless( [
autom4te: '2',
autom4te: 0,
autom4te: [
autom4te: '/opt/local/share/autoconf'
autom4te: ],
autom4te: [
autom4te: '/opt/local/share/autoconf/m4sugar/m4sugar.m4',
autom4te: '/opt/local/share/autoconf/m4sugar/m4sh.m4',
autom4te: '/opt/local/share/autoconf/autoconf/autoconf.m4',
autom4te: 'aclocal.m4',
autom4te: 'configure.ac'
autom4te: ],
autom4te: {
autom4te: '_LT_AC_TAGCONFIG' => 1,
autom4te: 'AM_PROG_F77_C_O' => 1,
autom4te: 'AC_INIT' => 1,
autom4te: 'm4_pattern_forbid' => 1,
autom4te: '_AM_COND_IF' => 1,
autom4te: 'AC_CANONICAL_TARGET' => 1,
autom4te: 'AC_SUBST' => 1,
autom4te: 'AC_CONFIG_LIBOBJ_DIR' => 1,
autom4te: 'AC_FC_SRCEXT' => 1,
autom4te: 'AC_CANONICAL_HOST' => 1,
autom4te: 'AC_PROG_LIBTOOL' => 1,
autom4te: 'AM_INIT_AUTOMAKE' => 1,
autom4te: 'AM_PATH_GUILE' => 1,
autom4te: 'AC_CONFIG_SUBDIRS' => 1,
autom4te: 'AM_AUTOMAKE_VERSION' => 1,
autom4te: 'LT_CONFIG_LTDL_DIR' => 1,
autom4te: 'AC_REQUIRE_AUX_FILE' => 1,
autom4te: 'AC_CONFIG_LINKS' => 1,
autom4te: 'm4_sinclude' => 1,
autom4te: 'LT_SUPPORTED_TAG' => 1,
autom4te: 'AM_MAINTAINER_MODE' => 1,
autom4te: 'AM_NLS' => 1,
autom4te: 'AM_GNU_GETTEXT_INTL_SUBDIR' => 1,
autom4te: 'AM_MAKEFILE_INCLUDE' => 1,
autom4te: '_m4_warn' => 1,
autom4te: 'AM_PROG_CXX_C_O' => 1,
autom4te: '_AM_COND_ENDIF' => 1,
autom4te: '_AM_MAKEFILE_INCLUDE' => 1,
autom4te: 'AM_ENABLE_MULTILIB' => 1,
autom4te: 'AM_SILENT_RULES' => 1,
autom4te: 'AM_PROG_MOC' => 1,
autom4te: 'AC_CONFIG_FILES' => 1,
autom4te: 'include' => 1,
autom4te: 'LT_INIT' => 1,
autom4te: 'AM_PROG_AR' => 1,
autom4te: 'AM_GNU_GETTEXT' => 1,
autom4te: 'AC_LIBSOURCE' => 1,
autom4te: 'AM_PROG_FC_C_O' => 1,
autom4te: 'AC_CANONICAL_BUILD' => 1,
autom4te: 'AC_FC_FREEFORM' => 1,
autom4te: 'AH_OUTPUT' => 1,
autom4te: '_AM_SUBST_NOTMAKE' => 1,
autom4te: 'AC_CONFIG_AUX_DIR' => 1,
autom4te: 'sinclude' => 1,
autom4te: 'AM_PROG_CC_C_O' => 1,
autom4te: 'm4_pattern_allow' => 1,
autom4te: 'AM_XGETTEXT_OPTION' => 1,
autom4te: 'AC_CANONICAL_SYSTEM' => 1,
autom4te: 'AM_CONDITIONAL' => 1,
autom4te: 'AC_CONFIG_HEADERS' => 1,
autom4te: 'AC_DEFINE_TRACE_LITERAL' => 1,
autom4te: 'AM_POT_TOOLS' => 1,
autom4te: 'm4_include' => 1,
autom4te: '_AM_COND_ELSE' => 1,
autom4te: 'AC_SUBST_TRACE' => 1
autom4te: }
autom4te: ], 'Autom4te::Request' );
autom4te: running: /opt/local/bin/gm4 --nesting-limit=1024 --gnu --include=/opt/local/share/autoconf
--debug=aflq --fatal-warning --debugfile=autom4te.cache/traces.2t --trace=AC_CANONICAL_BUILD
--trace=AC_CANONICAL_HOST --trace=AC_CANONICAL_SYSTEM --trace=AC_CANONICAL_TARGET --trace=AC
CONFIG_AUX_DIR --trace=AC_CONFIG_FILES --trace=AC_CONFIG_HEADERS --trace=AC_CONFIG_LIBOBJ_DIR
--trace=AC_CONFIG_LINKS --trace=AC_CONFIG_SUBDIRS --trace=AC_DEFINE_TRACE_LITERAL
--trace=AC_FC_FREEFORM --trace=AC_FC_SRCEXT --trace=AC_INIT --trace=AC_LIBSOURCE
--trace=AC_PROG_LIBTOOL --trace=AC_REQUIRE_AUX_FILE --trace=AC_SUBST --trace=AC_SUBST_TRACE
--trace=AH_OUTPUT --trace=AM_AUTOMAKE_VERSION --trace=AM_CONDITIONAL --trace=AM_ENABLE_MULTILIB
--trace=AM_GNU_GETTEXT --trace=AM_GNU_GETTEXT_INTL_SUBDIR --trace=AM_INIT_AUTOMAKE
--trace=AM_MAINTAINER_MODE --trace=AM_MAKEFILE_INCLUDE --trace=AM_NLS --trace=AM_PATH_GUILE
--trace=AM_POT_TOOLS --trace=AM_PROG_AR --trace=AM_PROG_CC_C_O --trace=AM_PROG_CXX_C_O
--trace=AM_PROG_F77_C_O --trace=AM_PROG_FC_C_O --trace=AM_PROG_MOC --trace=AM_SILENT_RULES
--trace=AM_XGETTEXT_OPTION --trace=LT_CONFIG_LTDL_DIR --trace=LT_INIT --trace=LT_SUPPORTED_TAG
--trace=_AM_COND_ELSE --trace=_AM_COND_ENDIF --trace=_AM_COND_IF --trace=_AM_MAKEFILE_INCLUDE
--trace=_AM_SUBST_NOTMAKE --trace=_LT_AC_TAGCONFIG --trace=_m4_warn --trace=include
--trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid --trace=m4_sinclude
--trace=sinclude /opt/local/share/autoconf/m4sugar/m4sugar.m4
/opt/local/share/autoconf/m4sugar/m4sh.m4 /opt/local/share/autoconf/autoconf/autoconf.m4 aclocal.m4
configure.ac > autom4te.cache/output.2t
autom4te: formatting traces for `/var/folders/KA/KA1QuiE6GRW0LBJLfWWhkU+++TI/-Tmp-//am4t1cP0fR/warnings': _m4_warn
autom4te: reading /var/folders/KA/KA1QuiE6GRW0LBJLfWWhkU+++TI/-Tmp-//am4t1cP0fR/warnings
autom4te: creating configure
autom4te: formatting traces for `/var/folders/KA/KA1QuiE6GRW0LBJLfWWhkU+++TI/-Tmp-//am4t1cP0fR/patterns': m4_pattern_allow, m4_pattern_forbid
autom4te: forbidden tokens: ^_?A[CHUM]_|_AC_|^LIBOBJS$|^_?m4_|^dnl$|^_?AS_|^_?LT_[A-Z_]+$|^_?PKG_[A-Z_]+$
autom4te: forbidden token : ^LIBOBJS$ => do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS'
autom4te: allowed tokens: ^AS_FLAGS$|^SHELL$|^PATH_SEPARATOR$|^PACKAGE_NAME$|^PACKAGE_TARNAME$|^PACKAGE_VERSION$|^PACKAGE_STRING$|
^PACKAGE_BUGREPORT$|^PACKAGE_URL$|^exec_prefix$|^prefix$|^program_transform_name$|^bindir$|^sbindir$|^libexecdir$|^datarootdir$|
^datadir$|^sysconfdir$|^sharedstatedir$|^localstatedir$|^includedir$|^oldincludedir$|^docdir$|^infodir$|^htmldir$|^dvidir$|^pdfdir$|
^psdir$|^libdir$|^localedir$|^mandir$|^PACKAGE_NAME$|^PACKAGE_TARNAME$|^PACKAGE_VERSION$|^PACKAGE_STRING$|^PACKAGE_BUGREPORT$|^PACKAGE_URL$|
^DEFS$|^ECHO_C$|^ECHO_N$|^ECHO_T$|^LIBS$|^build_alias$|^host_alias$|^target_alias$|^AM_[A-Z]+FLAGS$|^INSTALL_PROGRAM$|^INSTALL_SCRIPT$|
^INSTALL_DATA$|^am__isrc$|^CYGPATH_W$|^PACKAGE$|^VERSION$|^PACKAGE$|^VERSION$|^ACLOCAL$|^AUTOCONF$|^AUTOMAKE$|^AUTOHEADER$|^MAKEINFO$|
^install_sh$|^STRIP$|^INSTALL_STRIP_PROGRAM$|^MKDIR_P$|^mkdir_p$|^AWK$|^SET_MAKE$|^am__leading_dot$|^AMTAR$|^am__tar$|^am__untar$|
^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$|^LIBTOOL$|^build$|^build_cpu$|^build_vendor$|^build_os$|^host$|^host_cpu$|
^host_vendor$|^host_os$|^CC$|^CFLAGS$|^LDFLAGS$|^LIBS$|^CPPFLAGS$|^CC$|^CC$|^CC$|^CC$|^ac_ct_CC$|^EXEEXT$|^OBJEXT$|^DEPDIR$|^am__include$|
^am__quote$|^AMDEP_TRUE$|^AMDEP_FALSE$|^AMDEPBACKSLASH$|^am__nodep$|^CCDEPMODE$|^am__fastdepCC_TRUE$|^am__fastdepCC_FALSE$|^SED$|^GREP$|
^EGREP$|^FGREP$|^GREP$|^LD$|^DUMPBIN$|^ac_ct_DUMPBIN$|^DUMPBIN$|^NM$|^LN_S$|^OBJDUMP$|^OBJDUMP$|^DLLTOOL$|^DLLTOOL$|^AR$|^ac_ct_AR$|^STRIP$|
^RANLIB$|LT_OBJDIR|^LT_OBJDIR$|^MANIFEST_TOOL$|^DSYMUTIL$|^NMEDIT$|^LIPO$|^OTOOL$|^OTOOL64$|^CPP$|^CPPFLAGS$|^CPP$|^STDC_HEADERS$|
^HAVE_DLFCN_H$|^CC$|^CFLAGS$|^LDFLAGS$|^LIBS$|^CPPFLAGS$|^CC$|^CC$|^CC$|^CC$|^ac_ct_CC$|^CCDEPMODE$|^am__fastdepCC_TRUE$|
^am__fastdepCC_FALSE$|^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$|^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|
DEBUG_SPEW)$|^PKG_CONFIG$|^PKG_CONFIG_PATH$|^PKG_CONFIG_LIBDIR$|^PKG_CONFIG$|^ALSA_CFLAGS$|^ALSA_LIBS$|^HAVE_LIBASOUND$|^HAVE_ALSA_TRUE$|
^HAVE_ALSA_FALSE$|^STDC_HEADERS$|^int32_t$|^int64_t$|^size_t$|^_UINT32_T$|^uint32_t$|^_UINT8_T$|^uint8_t$|^LIBM$|^LIBOBJS$|^LTLIBOBJS$|
^am__EXEEXT_TRUE$|^am__EXEEXT_FALSE$
when I than call:
./configure --prefix=/usr
I get:
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

config.log shows this:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by dcaenc configure 2, which was
generated by GNU Autoconf 2.68. Invocation command line was

$ ./configure --prefix=/usr

## --------- ##
## Platform. ##
## --------- ##

hostname = macmini.local
uname -m = i386
uname -r = 10.8.0
uname -s = Darwin
uname -v = Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = Mach kernel version:
Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386
Kernel configured for up to 2 processors.
2 processors are physically available.
2 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1
Primary memory available: 2.00 gigabytes
Default processor set: 52 tasks, 229 threads, 2 processors
Load average: 0.44, Mach factor: 1.56
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

-> Does anyone know how to fix this?

Cu Selur

Ps.: Same happens on my linux systems,...

[Selur]

got it working!
The main problem was a conflict between autoconf <> automake <> m4 <> libtool versions,... ARGH,...

Cu Selur

[Midzuki]

To whom this may interest :) ,
here go the channel-orders required by the current version of dcaenc for the correct encoding of the channel layouts that "nobody uses" :rolleyes:

[2/1] ( dcaenc -c 7 )

FR, BC, FL

[2/0 + LFE] ( dcaenc -c 3 -f )

FR, LFE, FL

[2/1 + LFE] ( dcaenc -c 7 -f )

FL, FR, BC, LFE

[3/0] ( dcaenc -c 6 )

FL, FR, FC

[3/0 + LFE] ( dcaenc -c 6 -f )

FC, FL, FR, LFE

[3/1] ( dcaenc -c 8 )

FC, FL, FR, BC

[3/1 + LFE] ( dcaenc -c 8 -f )

FL, FR, FC, BC, LFE

[4/0 + LFE] ( dcaenc -c 9 -f )

FR, BL, FL, BR, LFE

[mariner]

Greetings. A few beginner's questions:

1. Can dcaenc encode 6-channel LPCM (>4GB) into dts-ma lossless? If yes, appreciate if some one can provide command line instruction starting with using eac3to to demux from m2ts file. Should W64 extension be used?

2. If not, is there any advantage using dts over 640kbps AC3? Again, command line instructions appreciated.

Many thanks and best regards.

[Selur]

Can dcaenc encode 6-channel LPCM (>4GB) into dts-ma lossless?
Nope, dcaenc 'only' creates dts and not dts-ma output.

If not, is there any advantage using dts over 640kbps AC3?
if you use the same bit rates probably not :)

[mariner]

Nope, dcaenc 'only' creates dts and not dts-ma output.


if you use the same bit rates probably not :)

Thanks for the kind reply, Selur.

What's the highest bit rate you'd recommend that's Blu-ray compatible?

[Selur]

1510 kBit/s probably gives the best hardware compatibility

[mariner]

Thanks.

1. What would be the files size for 90 min 6-channl track?
2. Is this lossless? It seems most DTS-HD MA lossless track has 1509 kbps rates.
3. Can eac3to do the same?

[Selur]

1 -> do the math yourself,.. 90min = 90*50 seconds with 1509 000 kBit per second you get 4527000000 bit
2 -> No, it's not lossless and not the DTS-MA extension is normally 1509 kBit/s the DTS core normally is.
3 -> no clue, I never use eac3to

[mariner]

Many thanks and best regards, Selur.

[tebasuna51]

...
3. Can eac3to do the same?

Some post about how use eac3to to encode with dcaenc moved to new thread dcaenc and eac3to (http://forum.doom9.org/showthread.php?p=1617506#post1617506) by Selur petition.

[Selur]

btw. did anyone compile a new version based on the latest updates with LorD_MuldeRs patch?

[SeeMoreDigital]

btw. did anyone compile a new version based on the latest updates with LorD_MuldeRs patch?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?

[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]

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]

@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]

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 : –/

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:


> 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.