anyone compiled and tried dcaenc ?

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