Log in

View Full Version : OggDec and friends with Unicode support?


LoRd_MuldeR
1st December 2010, 21:50
Hello.

Can anybody point me to a Win32 build of OggDec.exe (should be a static build) with Unicode support enabled?

The build of "oggdec v1.9.7" from RareWares.org (http://www.rarewares.org/ogg-oggdec.php) doesn't handle Unicode file names (although their OggEnc2 build does perfectly!) and the provided source code package is incomplete.

I also tried the "vorbis-tools" from the official Vorbis web-site, but apparently the VisualStudio project files are broken/outdated and the pre-compiled Win32 binaries aren't Unicode-capable either...

Thanks in advance! :)

LoRd_MuldeR
2nd December 2010, 21:12
Okay, this evening I managed to compile OggDec from the sources and I hacked in Unicode support. It is ugly, but it seems to work ;)

dansrfe
3rd December 2010, 02:55
it would be cool to implement ogg encoding in eac3to. but I guess something like AAC surpasses that already. I'm still unsure where ogg lies on "the scale".

tebasuna51
3rd December 2010, 11:04
it would be cool to implement ogg encoding in eac3to.
You always can use something like:

eac3to input stdout.wav | OggEnc2 -q 3 --ignorelength -o output.ogg -

LoRd_MuldeR
3rd December 2010, 13:05
You always can use something like:

eac3to input stdout.wav | OggEnc2 -q 3 --ignorelength -o output.ogg -

Using stdin/stdout would be one workaround, but in my specific situation it would make things much more complicated/unelegant.

The "proper" solution still is native Unicode support. And in the meantime I managed to hack Unicode support into both, OggDec and FAAD2.

Haven't tested my own builds much, but apparently it seems to work as desired :)

(BTW: Passing short path names is NOT a solution either, because they aren't reliable - there's no guarantee a particular long path names has a corresponding short name. Also many CLI tools try to expand short names - apparently by using the ANSI version of FindFirstFile() - and thus will fail as the "expanded" path will containing nasty "?" characters once again *sigh*)

LoRd_MuldeR
20th December 2010, 00:25
Okay, as a side-product of my efforts to re-write LameXP with proper Unicode support, I hacked in Unicode filename support into various audio CLI tools.

As this might be helpful for others, I have uploaded a snapshot of my current tool chain:
http://www.mediafire.com/file/ry1gk2a5rsna42h/unicode-audio-tools.2010-12-20.rar

(BTW: The OggEnc2 compiles available from Rarewares.org already support Unicode filenames, for LAME you'll need to update to version 3.99)

tebasuna51
22nd December 2010, 03:37
Warning with the valdec.exe, included in the package, when decode dts the output is +3dB than original and peaks are distorted.

LoRd_MuldeR
22nd December 2010, 14:13
Warning with the valdec.exe, included in the package, when decode dts the output is +3dB than original and peaks are distorted.

Strange. Did you check this against the valdec.exe reference binary from ac3filter.net? (latest version)

I did not change anything in the decoder library itself, only in the CLI front-end. Maybe a compiler issue?

LoRd_MuldeR
22nd December 2010, 18:12
Strange. Did you check this against the valdec.exe reference binary from ac3filter.net? (latest version)

I did not change anything in the decoder library itself, only in the CLI front-end. Maybe a compiler issue?

Update:

I just arrived at home and I decoded the same DTS file twice, once with the "official" valdec.exe binary (AC3Filter Tools v0.31b) from http://ac3filter.net/ and once with my own binary (based on AC3Filter Tools v0.31b source, compiled with VC2008/ICL11). Both output Wave files came out bit-identical:

74fcc04f04f78b6f1124cfb362d496b74a9da790 DTS_TEST_MINE.wav
74fcc04f04f78b6f1124cfb362d496b74a9da790 DTS_TEST_ORIG.wav

So can you please give me an sample to reproduce the issue?

tebasuna51
22nd December 2010, 19:19
Yes, also the Ac3Filter have the bug, to obtain the exact volume than input we need put Master volume to -3 dB.
Isn't your compiled version, is the original source.

Decode your sample with eac3to (ArcSoft, Sonic or libav), Foobar2000, NicDTSsource, ... and you can see the volume difference.

LoRd_MuldeR
22nd December 2010, 19:29
Yes, also the Ac3Filter have the bug, to obtain the exact volume than input we need put Master volume to -3 dB.
Isn't your compiled version, is the original source.

Decode your sample with eac3to (ArcSoft, Sonic or libav), Foobar2000, NicDTSsource, ... and you can see the volume difference.

If the problem occurs with the original AC3 Filter (Valib) code already and is not my fault, it should better be discussed with the AC3 Filter author.

I'm certainly not going to mess with the core library, except if the fix was trivial ;)

LoRd_MuldeR
27th December 2010, 16:14
Small update:
http://code.google.com/p/mulder/downloads/detail?name=unicode-audio-tools.2010-12-27.rar&can=2&q=

LoRd_MuldeR
17th January 2011, 00:34
Today I added MAC (Monkey's Audio) to the Unicode collection:
http://code.google.com/p/mulder/downloads/detail?name=unicode-audio-tools.2011-01-17.rar&q=