Log in

View Full Version : anyone compiled and tried dcaenc ?


Pages : 1 2 3 4 [5] 6 7

LoRd_MuldeR
11th January 2012, 01:38
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
11th January 2012, 02:51
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
11th January 2012, 04:44
^
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
11th January 2012, 04:49
or you can pipe using eac3to....
_

Midzuki
11th January 2012, 04:56
^

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

Midzuki
11th January 2012, 05:07
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
11th January 2012, 14:47
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
11th January 2012, 21:29
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
12th January 2012, 03:02
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
12th January 2012, 04:21
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
12th January 2012, 05:00
@nu774 thanks a lot...
_

Midzuki
12th January 2012, 11:57
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
12th January 2012, 14:56
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
12th January 2012, 14:57
Nice,thanks !

LoRd_MuldeR
12th January 2012, 16:16
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
12th January 2012, 19:51
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
12th January 2012, 20:42
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
12th January 2012, 21:48
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
12th January 2012, 23:31
New build seems to work. :)

Cu Selur

geminigod
13th January 2012, 00:17
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
13th January 2012, 00:25
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
13th January 2012, 00:41
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
13th January 2012, 09:15
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
13th January 2012, 18:10
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
13th January 2012, 18:28
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
13th January 2012, 18:39
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
13th January 2012, 19:16
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
13th January 2012, 19:32
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
14th January 2012, 14:55
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
14th January 2012, 15:11
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
14th January 2012, 15:30
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
14th January 2012, 15:34
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
14th January 2012, 15:43
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
14th January 2012, 17:12
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
14th January 2012, 17:38
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
14th January 2012, 17:53
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
14th January 2012, 18:33
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
14th January 2012, 19:03
^ 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
14th January 2012, 19:57
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
14th January 2012, 21:52
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
14th January 2012, 22:19
With SoX, you can simply add "-b 16" or "-b 32" to do the required conversion.

tebasuna51
15th January 2012, 01:52
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
15th January 2012, 02:12
@ 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
15th January 2012, 02:27
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
15th January 2012, 13:13
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
15th January 2012, 13:49
...
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
15th January 2012, 14:19
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
15th January 2012, 14:51
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
16th January 2012, 16:12
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
19th January 2012, 09:27
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.