anyone compiled and tried dcaenc ?

[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