ffdcaenc 2.1.3

[filler56789]

ffdcaenc (Free Fast DTS Encoder) is a fork from mulders-dtsenc. It adds support for 24 bit input files, multiple mono input files, flags for options needed for DTS CD and DVD, and changes the core dcaenc library to support DVD frame rates as expected by AudioMuxer and Muxman.

[moderator EDIT]
ffdcaenc v.2.1.3 (https://github.com/filler56789/ffdcaenc-2/releases) (2016-06-05)
[END moderator EDIT]

source: github.com/michailgm/ffdcaenc <= dead link

So could anyone please compile the .EXE?
Principally, a build that DOES NOT return the annoying

the procedure entry point _wfopen_s could not be located in the dynamic link library msvcrt.dll :mad:

______________________________________

UPDATE:

Since the original project page was deleted, here goes a new URL to ffdcaenc's source-code

— minus a "B.S." restriction in the README.TXT, because that restriction was not compatible with both the GPL and LGPL.

http://www.mediafire.com/download/n2q5c12as2k5xqb/ffdcaenc-master.7z (2014-07-28)

[LoRd_MuldeR]

source: https://github.com/michailgm/ffdcaenc

So could anyone please compile the .EXE?

Have fun ;)

Principally, a build that DOES NOT return the annoying
the procedure entry point _wfopen_s could not be located in the dynamic link library msvcrt.dll

Why should this be the case? :confused:

Binaries compiled with Visual Studio 2005 or newer do not depend on msvcrt.dll at all. Instead, they use a msvcrtX.dll (e.g. msvcrt120.dll), which is specific to the individual version of Visual Studio.

And of course that DLL will contain all functions that are available (i.e. could potentially be used) in the specific Visual Studio version...

[filler56789]

Thanks a lot, Mulder :thanks: :thanks: :thanks:

Why should this be the case?

Call me stupid if you wish :o :p , but I tried to compile it with MinGW ^.^;

[LoRd_MuldeR]

I see. But I'm surprised that MinGW/GCC supports _wfopen_s() at all, since it's a VisualStudio-specific non-standard extension.

Anyway, MinGW relies on the system-provided "msvcrt.dll". But in older Windows versions that one did not contain _wfopen_s(). So that's probably why you saw the error.

[filler56789]

Promise #1: checked ^^

and changes the core dcaenc library to support DVD bitrates as expected by AudioMuxer and Muxman

Important, it works ONLY for 48kHz and the DVD-compliant bitrates, i.e., 754.5 and 1509.75 kbps. All the other cases are filtered out by the old "4-byte granularity" (so that, for example, you can't encode a 48kHz source at 577.5 or 642.75 kbps, since these values are not integer multiples of 3).

[filler56789]

Promise #2: support for mono inputs = checked :)

Promise #3: support for 24-bit input = checked :)

ffdcaenc -v

{SNIP}

ffdtsenc-2.1.3
Compiled on Jul 27 2014 at 16:54:48 using MSVC Unknown.
http://aepatrakov.narod.ru/dcaenc/

:D

[filler56789]

Anyway, MinGW relies on the system-provided "msvcrt.dll". But in older Windows versions that one did not contain _wfopen_s(). So that's probably why you saw the error.

Thanks for the insight. So I just replaced the new "unicode_support.*" with the old ones,
re-added the missing files and folders, and voilà,

managed to compile an «XP-friendly» :devil: build ^_^

[Sparktank]

This looks pretty neat.
I should try some audio upgrades for my DVD conversions.

Thanks for the compile LoRd_MuldeR, thanks for the interest to get things rolling filler56789.

Will find time this week to have fun with it.

[Brazil2]

managed to compile an «XP-friendly» :devil: build ^_^
Would you share it ? :)

[filler56789]

^ It's not a "production model" yet, so I've sent you a P.M.

[Brazil2]

^ It's not a "production model" yet, so I've sent you a P.M.
Thanks :)

[Selur]

would be interested too once reached 'production model' level :)

[microchip8]

how come the github was taken down?

[filler56789]

how come the github was taken down?

Well... yesterday I e-mailed Patrakov and told him I had just found the ffdcaenc project, and I asked him,

"how about making those new features available to the Linux folks?"

Then he told me it wouldn't be possible, because according to him at least, Lord_Mulder's code uses both the GPL and the LGPL, and to him this is a reason "strong enough" to NOT import Lord_Mulder's modifications into his Linux-code :confused: And as ffdcaenc is a fork of Mulder's work, then Patrakov should refuse its improvements as well :–/

The header of the files says LGPL (acceptable), the help message says GPL (not acceptable for inclusion back into dcaenc).
As ffdcaenc is derived from a work with unclear license, the same unclearness applies to it.

Besides: the README.TXT from the ffdcaenc package included a "usage restriction" that is clearly incompatible with the GPL and the LGPL :scared: And instead of simply fixing the absurd README.TXT, the author of ffdcaenc preferred to remove the entire project from his GitHub directory :(

[LoRd_MuldeR]

Well... yesterday I e-mailed Patrakov and told him I had just found the ffdcaenc project, and I asked him,

"how about making those new features available to the Linux folks?"

Then he told me it wouldn't be possible, because according to him at least, Lord_Mulder's code uses both the GPL and the LGPL, and to him this is a reason "strong enough" to NOT import Lord_Mulder's modifications into his Linux-code :confused: And as ffdcaenc is a fork of Mulder's work, then Patrakov should refuse its improvements as well :–/

I don't know how that idea came up :confused:

First of all, mixing LGPL'd code with GPL'd code is perfectly fine and allowed. The combined work would have to be released under GPL, of course.

Secondly, my branch of "dcaenc" does not contain anything, except for the original code by Patrakov plus the modifications/code that I wrote myself.

Last but not least, all modifications/code I added to dcaenc are released under the same license as the original project. That is: LGPL.


Besides: the README.TXT from the ffdcaenc package included a "usage restriction" that is clearly incompatible with the GPL and the LGPL :scared: And instead of simply fixing the absurd README.TXT, the author of ffdcaenc preferred to remove the entire project from his GitHub directory :(

If somebody has the copyright on a piece of code, he can decide to release that code under whatever license he wishes. So, if that person decides to release his/her code under the GPL or LGPL but with certain additional restrictions, that is perfectly fine. Of course that code is then released under a modified GPL rather than the original GPL. But again, the original copyright holder is perfectly allowed to decide that way. The copyright holder can even decide to release his code under multiple incompatible licenses. A lot of popular projects are released under the GPL or LGPL and, at the same time, under some commercial/proprietary license. x264 is one example. Qt is another one.

Having said that, if somebody takes an existing code that was released under the original (L)GPL by the original authors, then the derivative work must be released under the original (L)GPL again - unless all copyright holders, i.e. all original authors, agree on the license change. Consequently, if somebody creates a derivative work based on code that had been released under the original (L)GPL'd, but then that person releases his/her derivative work under some license more restrictive than the (L)GPL, without explicit permission by the original authors, then these additional restrictions simply are ineffective. Furthermore, as soon as a specific version of a software has been released under the (L)GPL once, everybody can continue to use that version under the (L)GPL as long he or she wants - even if the original author decides to not release future versions of the software under the (L)GPL anymore.

[filler56789]

^ Thanks for the clarification, LoRd_MuldeR =^.^=

But before going back to the topic :o , I would like to add some background info...

I don't remember exactly how I found ffdcaenc, but when I found that name, via a custom Google search for dcaenc and ffmpeg
(or something like that, surely I was NOT looking for ffdcaenc),
the first results were links to (dead) torrent files :eek: , and according to their content descriptions,
the current version of ffdcaenc, 2.1.3, was already "set up and running" 13 months ago :scared: In summary,
I still don't understand how, or why, it took so long until some one of us became aware of its existence O_o

[michailgm]

I want to take this opportunity to express my great thanks to Alexei Andropov, and to all who helped DTS encoder to evolve and improve.

[filler56789]

For the time being, just a "Test Type" build,

http://www.mediafire.com/download/a8mbtise2zpjjpq/ffdcaenc-213_MinGW-w64_20140729.7z

And below, a non-Unicode release,

http://www.mediafire.com/download/ljb6cx68sujxz4m/ffdcaenc-213_non-unicode_20140729.7z

--- NOTE ---

Sadly the mono inputs option does not support the channel-layouts that include the back-center channel, so we still need the old sox workaround:

[1.1]
sox -M FC.wav LFE.wav -t wavpcm -|ffdcaenc -i - -o zzzzFCp1.dts -b 256 -c 1 -f

[2/1]
sox -M FR.wav BC.wav FL.wav -t wavpcm -|ffdcaenc -i - -o 2f1r0p.dts -b 672 -c 7

[2/0 + LFE]
sox -M FR.wav LFE.wav FL.wav -t wavpcm -|ffdcaenc -i - -o 2f0r1p.dts -b 576 -c 3 -f

[2/1 + LFE]
sox -M FL.wav FR.wav BC.wav LFE.wav -t wavpcm -|ffdcaenc -i - -o 2f1r1p.dts -b 840 -c 7 -f

[3/0]
sox -M FL.wav FR.wav FC.wav -t wavpcm -|ffdcaenc -i - -o 3f0r0p.dts -b 768 -c 6

[3/0 + LFE]
sox -M FC.wav FL.wav FR.wav LFE.wav -t wavpcm -|ffdcaenc -i - -o 3f1p.dts -b 882 -c 6 -f

[3/1]
sox -M FC.wav FL.wav FR.wav BC.wav -t wavpcm -|ffdcaenc -i - -o 3f1r0p.dts -b 960 -c 8

[3/1 + LFE]
sox -M FL.wav FR.wav FC.wav BC.wav LFE.wav -t wavpcm -|ffdcaenc -i - -o 3f1r1p.dts -b 1024 -c 8 -f

[4/0 + LFE]
sox -M FR.wav BL.wav FL.wav BR.wav LFE.wav -t wavpcm -|ffdcaenc -i - -o qf0r1p.dts -b 1152 -c 9 -f

[filler56789]

Very-well, I suppose (and hope :o ) I have found the way to make ffdcaenc *NIX-friendly...
To whom would like to try to compile the cleaned-up source-code, here is the URL:

http://www.mediafire.com/download/76htfufhp7t1bgp/LUNIX-test.7z

INSTRUCTIONS:

autoreconf -f -i -v

./configure --disable-alsa --disable-shared --enable-static

make

[filler56789]

After some cosmetic tweaks in the files main.c and ffdcaenc.h, here it is, the "production model" (or at least I think so).
According to Selur (many :thanks: to him), this code is compilable under Linux, and the warning messages can be safely ignored.

[microchip8]

Very-well, I suppose (and hope :o ) I have found the way to make ffdcaenc *NIX-friendly...
To whom would like to try to compile the cleaned-up source-code, here is the URL:

http://www.mediafire.com/download/76htfufhp7t1bgp/LUNIX-test.7z

INSTRUCTIONS:

autoreconf -f -i -v

./configure --disable-alsa --disable-shared --enable-static

make

Just tried it. Compiles fine and ffdcaenc works fine :)

[filler56789]

Great! :)

Thanks for testing and confirming =^.^=

[microchip8]

Great! :)

Thanks for testing and confirming =^.^=

Have a question, though. Are you planning to maintain/further develop ffdcaenc in some form, maybe on github or so?

If that's the case, I may include it in my scripts

[filler56789]

Nope, because I am not a programmer since the days that the 96-column punch cards were still used ^.^;

All I wanted was just make the improvements created by Lord_Mulder (and now, by Alexei Andropov too) available to the *NIX users, so that their better builds of (ff)dcaenc don't depend on WINE anymore :)

But if I just could, I certainly would fix the issues with the "uncommon" channel-layouts and
would add the back-center channel to the mono inputs option =^_^=

FWIW, these were the steps of the RE-Linuxization:

1) internal renaming from dcaenc to ffdcaenc

2) add _T(__GNUC_PATCHLEVEL__) to compiler_info.h

3) drop the Windows-specific Unicode support

4) replace all the occurrences of __int8 and __int32 with int8_t and int32_t , plus

5) replace "unsigned __int8" and "unsigned __int32" with "uint8_t" and "uint32_t"

6) remove the MSVC stuff from (ff)dcaenc.h

7) replace %d and %02d with %u and %02u in the file main.c, in order to eliminate the warning messages

[filler56789]

Well, certainly not because of some good-intention ^.^; ,
but I have changed my mind :)

https://github.com/filler56789/ffdcaenc-2

[Sparktank]

I managed to get one DVD going.
HCenc + AC3 + DTS (754.5 kbps for DVD authoring).
It built propery with Muxman and managed to get it into an ISO with ImgBurn.
I still have to test if it works on my devices though. That's another ballpark.

For testing, I took a 24bit audio track and made 3 versions: 16bit (eac3to -down16), 24bit (original), s32 (ffmpeg)
Ran them all though ffdcaenc and the file size was the same for all.
I decoded all three to WAV with eac3to+arcsoft then eac3to+libav and ram them through Foobar2000's "bit comparator", only mild audio differnces were found between all of them.

Not sure if upscaling 24->32 did anything, since there's no new data and I didn't apply any filtering.

I do like it supports 24bit, since 16 & 24 are the common bit depths for blu-ray audio formats, so i don't needlessly have to upscale to s32.

However, it seems no matter the source, it writes the DTS with 24bit, which is unusable in AVStoDVD (since AVS to accept only 16/20 bit DTS streams for maximum compatibility wtih Muxman).
Using Muxman manually (without AVStoDVD), I was able to get the 24bit DTS stream to mux.

This is still incredibly fun to play with.

[tebasuna51]

@Sparktank
Please read the last pages in eac3to thread.

- The standard dts don't have bitdepth, the size is always the same no matter the bitdepth of source wav because the bitrate is the same.

- The 32 bits float have, more or less, the same precission than 24 bits int, because 32 float have 24 bits for mantissa (significand digits). It's usefull only when you need operate with the values to prevent int overflow.

- If AVStoDVD don't accept a DTS marked with a source PCM of 24 bits is only a bug in the program. The DTS header field about Source PCM Resolution must be ignored.

[Sparktank]

@Sparktank
Please read the last pages in eac3to thread.

- The standard dts don't have bitdepth, the size is always the same no matter the bitdepth of source wav because the bitrate is the same.

Thanks for adding a lot of input.

I did spend some time reading eac3to thread lately and had wondered if this was mostly just A2D concern about its bit-depth and DTS formats.

- The 32 bits float have, more or less, the same precission than 24 bits int, because 32 float have 24 bits for mantissa (significand digits). It's usefull only when you need operate with the values to prevent int overflow.

32 float, that reminds me, I don't believe this program uses float. I think it prefers 32 integer instead.
The documentation says there's a known bug about floating-point:

Known bug: wav files with floating-point samples are misinterpreted as
containing 32-bit integer samples.


- If AVStoDVD don't accept a DTS marked with a source PCM of 24 bits is only a bug in the program. The DTS header field about Source PCM Resolution must be ignored.

I should visit the A2D thread, but after some extensive testing and samples done for evidence.
It would be nice to see something like this implemented into A2D, since I use most of what it uses.

----------

All this FF play, and I still haven't gotten around to actually trying Mulder's version (of which this is a fork of).
I'll have to set up a day for all this.

[MrC]

- If AVStoDVD don't accept a DTS marked with a source PCM of 24 bits is only a bug in the program. The DTS header field about Source PCM Resolution must be ignored.

That was a decision of mine of some times ago: most 16/20bit DTS streams are accepted by Muxman and more than few 24bit DTS streams are rejected by Muxman.

I have tried to search what is the real culprit to know if a DTS stream is DVD compliant (aka accepted by Muxman), without success. That's why I have implemented in AVStoDVD the 16/20 vs 24 bit approximate rationale.

I would happily change the rationale, if anyone can suggest how to define in advance (i.e. thru Mediainfo) if a DTS stream is DVD compliant (accepted by Muxman).

Thanks guys!

;)

Bye

[SeeMoreDigital]

I have tried to search what is the real culprit to know if a DTS stream is DVD compliant (aka accepted by Muxman), without success. That's why I have implemented in AVStoDVD the 16/20 vs 24 bit approximate rationale.

The most likely culprit is that the DVD specification requires an elementary DTS stream to be encoded with 2012 primary (2013 bytes) per frame ;)

[MrC]

The most likely culprit is that the DVD specification requires an elementary DTS stream to be encoded with 2013 bytes per frame ;)

That's interesting, many thanks for the quick reply. Any docs to support that spec? How can I extract this info from an audio stream? AFAIK bytes/frame is not part of MediaInfo output... :(

;)

Bye

P.S. If we are going OT, we can continue on the AVStoDVD thread.

[SeeMoreDigital]

How can I extract this info from an audio stream? AFAIK bytes/frame is not part of MediaInfo output... :(
Personally, I use an application called DTSParser.

I discovered this issue only recently myself a few months, ago here (http://forum.doom9.org/showthread.php?t=170061)...

[tebasuna51]

The tool I use in the post linked by SeeMoreDigital is LeeAudbi (http://forum.doom9.org/showthread.php?p=1522330#post1522330)

Maybe you can use the LeeDtsBi.exe, out of the GUI, than output the file AudioBi.log:
==========================================================
File ........: D:\tmp\test 4\321.dts
Size ........: 1886250 bytes

----------------------------------------- First Frame Info
CRC present .................: 0 (Not)
Number of PCM Sample Blocks .: 15 ( 512 samples/frame)
Primary Frame Byte Size .....: 1005 ( 1006 bytes/frame)
Audio Channel Arrangement ...: 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency ..: 13 (48 kHz)
Transmission Bit Rate .......: 15 (768 Kb/s)
Embedded Down Mix Enabled ...: 0 (Not)
Embedded Dynamic Range Flag .: 0 (Not)
Embedded Time Stamp Flag ....: 0 (Not)
Auxiliary Data Flag .........: 0 (Not)
Mastered in HDCD format .....: 0 (Not)
Extension Audio Descr. Flag .: 0 (Channel Extension XCh)
Extended Coding Flag ........: 0 (Not)
Audio Sync Word Insert. Flag : 1 (Sub-sub-frame)
Low Frequency Effects Flag ..: 2 (Present, interpolation factor 64)
Predictor History Flag Switch: 1 (Yes)
Multirate Interpolator Switch: 0 (Non-perfect Reconstruction)
Encoder Software Revision ...: 7 (Current)
Copy History ................: 1 (Definition deliberately omitted)
Source PCM Resolution .......: 6 (24 bits)
Front Sum/Difference Flag ...: 0 (Not)
Surrounds Sum/Difference Flag: 0 (Not)
Dialog Normalization Param. .: - 0 dB
------------------------------------------- Estimated Info
Total Frames ......: 1875
Duration ..........: 20 seconds. ( 0 h. 0 m. 20 s.)
------------------------------------------------- End Info


Here you can see a valid DTS with Transmission Bit Rate 768 Kb/s.
I don't know the Muxman requirements, but I don't think is related with the value of the field Source PCM Resolution that can be changed without modify the audio itself.

[MrC]

@tebasuna51

thanks for the info about LeeDtsBi, nice tool :)

Actually some years ago I had already contacted mpucoder who pointed me to this page for DTS compliance to DVD:
http://mpucoder.com/DVD/dtshdr.html

At that time it was quite obscure to me. Now it should be more clear thank to your explanations and achievable with LeeDtsBi.

Requirements (other than bitrate and samplerate):

Number of PCM Sample Blocks = 15
Primary Frame Byte Size = 1005 for 768 Kbps streams or 2012 for 1536 Kbps streams

;)

Bye

[filler56789]

I think I've found one of those "problematic 24-bit files" mentioned by MrC :)

http://forum.videohelp.com/threads/367078-Need-advice-about-mixing-5-1-down-to-stereo?p=2345872&viewfull=1#post2345872

[MrC]

@tebasuna51

I have seen that LeeDtsbi accepts only DTS files as input (well, it is designed for that, I assume .... :) ). Would it be possible to expand the scope by feeding also containers of DTS tracks, such as avi, vob, mkv?

Thanks in advance

;)

Bye

[tebasuna51]

Sorry, but I don't know how parse containers.

[filler56789]

^
^ MrC, I presume you can use a recent build of MediaInfo for that purpose. My copy is version 0.7.67, and until now, it deals fine (bitrate-wise) with all the "generic DTSs" :) that I have created with dcaenc :cool: Example:

General
Unique ID : 253922954119774177664030532708049754484 (0xBF07C83717D52580B6BF63AA47561974)
Complete name : D:\SomeDirectory\filename.mkv
Format : Matroska
Format version : Version 2
File size : 171 MiB
Duration : 10mn 13s
Overall bit rate : 2 333 Kbps
Encoded date : UTC 2010-02-22 21:41:31
Writing application : mkvmerge v5.8.0 ('No Sleep / Pillow') built on Sep 30 2012 10:57:14
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Video
ID : 1
Format : VC-1
Codec ID : V_MS/VFW/FOURCC / WMV3
Codec ID/Info : Windows Media Video 9
Codec ID/Hint : WMV3
Duration : 10mn 13s
Bit rate : 1 994 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.087
Stream size : 146 MiB (85%)
Default : Yes
Forced : No

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 10mn 13s
Bit rate mode : Constant
Bit rate : 292 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 21.4 MiB (13%)
Language : English
Default : Yes
Forced : No

If MediaInfo was wrong in this case, then it would keep "thinking" that «actual_bitrate == transmission_bitrate» ;)

[MrC]

@filler56789

thanks for looking into this. Actually I already use MediaInfo to scan video and audio properties. Unfortunately samplerate and bitrate are not sufficient to define if a DTS stream is DVD compliant. There are streams having 768/1536 Kbps and 48 KHz but are not DVD compliant. As mentioned before we need to check also:

Number of PCM Sample Blocks = 15
Primary Frame Byte Size = 1005 for 768 Kbps streams or 2012 for 1536 Kbps streams

as LeeDtsBi from tebasuna51 does.

I have already sent a feat request to Zenitram (MediaInfo author) to include the above properties. Let's wait for his reply.

;)

Bye

[filler56789]

@filler56789

thanks for looking into this. Actually I already use MediaInfo to scan video and audio properties. Unfortunately samplerate and bitrate are not sufficient to define if a DTS stream is DVD compliant.

Actually, they are sufficient, IF/WHEN reported correctly. At 48kHz, and with 512 samples per frame,

1006 bytes per frame = 754.500kbps
1024 bytes per frame = 768.000kbps

2013 bytes per frame = 1509.750kbps
2048 bytes per frame = 1536.000kbps

[SeeMoreDigital]

Try doing what I did and 'cheat' MuxMan into thinking the DTS stream is compliant...

All you have to do is chop-off and save a few milliseconds from the beginning of a compliant (2013 bytes/frame) elementary DTS stream. And add it to the beginning of your 'non compliant' elementary DTS stream ;)

[MrC]

Actually, they are sufficient, IF/WHEN reported correctly. At 48kHz, and with 512 samples per frame,

1006 bytes per frame = 754.500kbps
1024 bytes per frame = 768.000kbps

2013 bytes per frame = 1509.750kbps
2048 bytes per frame = 1536.000kbps

Good point, hence 'bytes per frame' is a derivative property, having bitrate and 'samples per frame'. Still we must be sure that:

'samples per frame' = 512

or is that a constant for DTS?

;)

Bye

[nevcairiel]

DTS can in theory go up to 4096 samples per frame, although 512 seems to be the most common at 48kHz.

[filler56789]

AFAIK, all DCA encoders available (and they are not many :) ) use 512 samples per audio frame.

Also, I presume/hope :o that eac3to, LeeAudBi and MediaInfo take the time to measure the frame size,
instead of assuming it always = 512 samples.

[tebasuna51]

512 is the standard value but is not mandatory.
From http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf

NBLKS (Number of PCM Sample Blocks)
This field indicates that there are (NBLKS+1) blocks (a block = 32 PCM core samples per channel, corresponding to
the number of PCM samples that are fed to the core filter bank to generate one subband sample for each subband) in the
current frame (see note). The actual core encoding window size is 32 × (NBLKS+1) PCM samples per channel. Valid
range for NBLKS: 5 to 127. Invalid range for NBLKS: 0 to 4. For normal frames, this indicates a window size of either
4 096, 2 048, 1 024, 512, or 256 samples per channel.

EDIT:
To know the Actual Bitrate you need the fields from DTS header:
NBLKS (Number of PCM Sample Blocks)

FSIZE (Primary Frame Byte Size)
(FSIZE+1) is the total byte size of the current frame including primary audio data as well as any extension audio data.
Valid range for FSIZE: 95 to 16 383. Invalid range for FSIZE: 0 to 94.

SFREQ (Core Audio Sampling Frequency)
This field specifies the sampling frequency of audio samples in the core encoder, based on Table 5-5:
Table 5-5: Core audio sampling (valid) frequencies
0b0001 8 kHz
0b0010 16 kHz
0b0011 32 kHz
0b0110 11,025 kHz
0b0111 22,05 kHz
0b1000 44,1 kHz
0b1011 12 kHz
0b1100 24 kHz
0b1101 48 kHz

Now the Actual Bitrate (in Kb/s if Sampling frequency in KHz) is:

8 x (FSIZE + 1) x Sampling-rate / (32 x (NBLKS + 1))

Examples:
8 x (2012 + 1) x 48 / (32 x (15 + 1)) = 1509,75 Kb/s
8 x (2011 + 1) x 48 / (32 x (15 + 1)) = 1509 Kb/s
8 x (1005 + 1) x 48 / (32 x (15 + 1)) = 754,5 Kb/s

Seems MediaInfo 0.7.70 (in Advanced mode) can detect the exact FSIZE for NBLKS 15 (standard value). For the 3 samples before:

Overall bit rate : 1509750
Overall bit rate : 1 510 Kbps

Overall bit rate : 1509000
Overall bit rate : 1 509 Kbps

Overall bit rate : 754500
Overall bit rate : 755 Kbps

EDIT 2:
I found dts's from surround Audio CD's with 1024 samples/frame:

Number of PCM Sample Blocks .: 31 ( 1024 samples/frame)
Primary Frame Byte Size .....: 3583 ( 3584 bytes/frame)
Audio Channel Arrangement ...: 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency ..: 8 (44,1 kHz)
Transmission Bit Rate .......: 22 (1411,2 Kb/s)

Actual Bitrate = 8 x (3583 + 1) x 44,1 / (32 x (31 + 1)) = 1234,8 Kb/s

MediaInfo show ok:
Bit rate : 1234800
Bit rate : 1 235 Kbps

BTW, ffdcaenc with -b 1411.2 for 44.1 KHz make:

Number of PCM Sample Blocks .: 15 ( 512 samples/frame)
Primary Frame Byte Size .....: 2047 ( 2048 bytes/frame)
Audio Channel Arrangement ...: 9 (5 C + L + R + SL + SR)
Core Audio Samp. Frequency ..: 8 (44,1 kHz)
Transmission Bit Rate .......: 22 (1411,2 Kb/s)
With Actual Bitrate = Transmission Bit Rate

[filler56789]

Thanks for the complete info, tebasuna51 :goodpost:

EDIT 2:
I found dts's from surround Audio CD's with 1024 samples/frame:

It would be very-interesting to know what was the software (or firmware?) that was used for producing that DCA stream...

BTW, and according to the file 4_dts-cae-4_cad-4_encode-decode.pdf (http://www.mediafire.com/download/t5a4ohkqf1iwblk/4_dts-cae-4_cad-4_encode-decode.pdf),
there exist two more "DVD-compliant" bitrates :confused:
(for 2.0 and 2.1 only),

503.25kbps and 377.25kbps :eek:

And yes, the «1-byte granularity» strikes again :scared:

EDIT: Wow, ffdcaenc already supports them too :eek: :cool:

File ........: D:\DVD-18\mlpdir\48tunntest.dts
Size ........: 4844620 bytes

----------------------------------------- First Frame Info
CRC present .................: 0 (Not)
Number of PCM Sample Blocks .: 15 ( 512 samples/frame)
Primary Frame Byte Size .....: 670 ( 671 bytes/frame)
Audio Channel Arrangement ...: 2 (2 L + R stereo)
Core Audio Samp. Frequency ..: 13 (48 kHz)
Transmission Bit Rate .......: 12 (512 Kb/s)
Embedded Down Mix Enabled ...: 0 (Not)
Embedded Dynamic Range Flag .: 0 (Not)
Embedded Time Stamp Flag ....: 0 (Not)
Auxiliary Data Flag .........: 0 (Not)
Mastered in HDCD format .....: 0 (Not)
Extension Audio Descr. Flag .: 0 (Channel Extension XCh)
Extended Coding Flag ........: 0 (Not)
Audio Sync Word Insert. Flag : 0 (Sub-frame)
Low Frequency Effects Flag ..: 0 (Not present)
Predictor History Flag Switch: 1 (Yes)
Multirate Interpolator Switch: 0 (Non-perfect Reconstruction)
Encoder Software Revision ...: 7 (Current)
Copy History ................: 0 (Definition deliberately omitted)
Source PCM Resolution .......: 6 (24 bits)
Front Sum/Difference Flag ...: 0 (Not)
Surrounds Sum/Difference Flag: 0 (Not)
Dialog Normalization Param. .: - 0 dB
--------------------------------------------- Revised Info
Total Frames ......: 7220
Duration ..........: 77.013 seconds. ( 0 h. 1 m. 17.013 s.)
------------------------------------------------- End Info

[SeeMoreDigital]

BTW, and according to the file 4_dts-cae-4_cad-4_encode-decode.pdf (http://www.mediafire.com/download/t5a4ohkqf1iwblk/4_dts-cae-4_cad-4_encode-decode.pdf),
there exist two more "DVD-compliant" bitrates :confused:
(for 2.0 and 2.1 only),

503.25kbps and 377.25kbps :eek:

And yes, the «1-byte granularity» strikes again :scared:

This being the case, it would probably make sense if the GUI's in DTS encoders were only able to offer the 'compliant' bit-rate levels, ie: 2.0 channel DTS-CD (if it exists), 5.1 channel DTS-CD, 2.0 channel DVD, 2.1 channel DVD, 5.1 channel DVD, etc...

[siella]

I tried ffdcaenc.exe-213_GCC.7z but stdin didnt work.

Input: -
Output: G:\001.dts
Bitrate: 1509 kbps

Encoding... 0:00 [100.0%]
Done.
stdin is working with ffdcaenc.2014-07-27.win32

[filler56789]

I tried ffdcaenc.exe-213_GCC.7z but stdin didnt work.

Input: -
Output: G:\001.dts
Bitrate: 1509 kbps

Encoding... 0:00 [100.0%]
Done.
stdin is working with ffdcaenc.2014-07-27.win32

Thanks for reporting.
I will TRY to fix the problem, since I'm not a programmer ---
--- therefore, no guarantees...

[filler56789]

FIXED - or at least I think so :o


637 #if defined(_WIN32) || defined(_WIN64)
638
639 #include <Windows.h>
640 #include <io.h>
641 #include <fcntl.h>
642
643 int32_t main( int32_t argc, char **argv )
644 {
645 _setmode(_fileno(stdin), _O_BINARY);
646 _setmode(_fileno(stdout), _O_BINARY);
647 return dcaenc_main(argc, argv);
648 }
649
650 #else
651
652 int32_t main( int32_t argc, char **argv )
653 {
654 return dcaenc_main(argc, argv);
655 }
656
657 #endif