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

______________________________________

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/n2...aenc-master.7z (2014-07-28)

[LoRd_MuldeR]

Originally Posted by filler56789

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

So could anyone please compile the .EXE?

Have fun

Originally Posted by filler56789

Principally, a build that DOES NOT return the annoying

Why should this be the case?

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

Why should this be the case?

Call me stupid if you wish , 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/

[filler56789]

Originally Posted by LoRd_MuldeR

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» build ^_^

[Brazil2]

Originally Posted by filler56789

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

Would you share it ?

[filler56789]

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

[Brazil2]

Originally Posted by filler56789

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

Thanks

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

[Selur]

would be interested too once reached 'production model' level

[microchip8]

how come the github was taken down?

[filler56789]

Originally Posted by froggy1

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

Originally Posted by filler56789

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

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.

Originally Posted by filler56789

Besides: the README.TXT from the ffdcaenc package included a "usage restriction" that is clearly incompatible with the GPL and the LGPL 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 , 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 , and according to their content descriptions,
the current version of ffdcaenc, 2.1.3, was already "set up and running" 13 months ago 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.

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

Originally Posted by 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.

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.

Originally Posted by tebasuna51

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

Originally Posted by tebasuna51

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