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

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

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

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

[filler56789]

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

http://www.mediafire.com/download/a8...64_20140729.7z

And below, a non-Unicode release,

http://www.mediafire.com/download/lj...de_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 ) 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/76.../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 to him), this code is compilable under Linux, and the warning messages can be safely ignored.