Aften 0.0.8 is out [Archive] - Page 15

wisodev

16th September 2007, 13:24

I have released version 0.6 of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html). You can download it from here (http://www.thefrontend.net/EncWAVtoAC3/index.html) or use direct download links placed below.

Download

Binary Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win32U-bin.zip?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win32A-bin.zip?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win64U-bin.zip?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win64A-bin.zip?download)
Installer Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win32U-installer.exe?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win32A-installer.exe?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win64U-installer.exe?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-Win64A-installer.exe?download)
Source Package: Visual C++ 2005 SP1 (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.6-src.zip?download)

Changelog

- Fixed bug in worker thread when used more then 2 Aften threads closing Aften caused memory leaks.
- Added automatic save/load for files list content to/from text file.
- Added options to enable/disable specific SIMD optimizations (-nosimd).
- Added support for RAW audio input files (-raw_fmt, -raw_sr, -raw_ch).
- Added number of threads, SIMD optimization and RAW audio settings to encoder preset config.
- Changed number of default parallel threads to Auto.
- Changed minimum width and height of main dialog (recommended screen resolution is now 1024x768 pixels).
- Added option to create output path when generating batch file (if output path doesn't exist).

Screenshots

http://img145.imageshack.us/img145/648/mainwndbiggd8.th.jpg (http://img145.imageshack.us/my.php?image=mainwndbiggd8.jpg)

Thanks,
wisodev

lolent

16th September 2007, 18:05

Please, anyone can tell me what channel order is HD DVD in 5.1 & 7.1 ?

totya

16th September 2007, 18:14

wisodev:

Thank you!

In parallel threads input line, default settings not selectable (<auto>). This is not bug, only intreresting.

wisodev

16th September 2007, 19:24

wisodev:

Thank you!

In parallel threads input line, default settings not selectable (<auto>). This is not bug, only intreresting.

When you delete text in the parallel threads edit box the program automatically fills the edit field (when focus in this field is lost) with <Auto>. It's the same trick I do for output path edit box. The <Auto> means that the encoder automatically chooses appropriate number of parallel threads depending on your hardware configuration (number of CPUs, cores etc.). Auto in internals of WAV to AC3 Encoder means 0 and it is only a label. This does the same as aften.exe command line switch -threads 0. I'm generally following the logic of aften command-line whenever I can. If this is too confusing let me know of better solution and I will implement it in the new version.

Thanks,
wisodev

totya

16th September 2007, 19:40

When you delete text in the parallel threads edit box the program automatically fills...

I see, thx :)

wisodev

25th September 2007, 23:21

I have released version 0.7 of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html). You can download it from here (http://www.thefrontend.net/EncWAVtoAC3/index.html) or use direct download links placed below.

Download

Binary Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win32U-bin.zip?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win32A-bin.zip?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win64U-bin.zip?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win64A-bin.zip?download)
Installer Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win32U-installer.exe?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win32A-installer.exe?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win64U-installer.exe?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-Win64A-installer.exe?download)
Source Package: Visual C++ 2005 SP1 (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.7-src.zip?download)

Changelog

- Added input file and output file detailed format informations to work dialog.
- Added quality, bandwidth an bitrate informations to work dialog (but currently not displayed).
- Added used SIMD optimizations and number of threads used informations to work dialog.
- Changed the way how the Auto and Ignored label are handled in edit boxes.
- Added parallel file encoding mode (set ParallelFileEncoding=true in *.config file and use number of parallel threads in main dialog).

Thanks,
wisodev

Yobbo

27th September 2007, 08:29

EDIT: dumb question sorry!

raquete

29th September 2007, 17:36

wisodev

29th September 2007, 17:48

wisodev,
first thank you for new version.

i have a problem: loading 5.1wave from audition in EncWAVtoAC3-0.7-Win32A-bin or in EncWAVtoAC3-0.7-Win32U-bin(default adjusts) i got a message.."this program is closed by windows..." etc.
loading the same 5.1 in EncWAVtoAC3 0.4 everything runs fine and i got the perfect result.
help please with the new version and thanks again!

There are some problems with my libaften.dll build! I'm working on this very hard. For now uncheck SSE SSE2 and SSE3 check boxes it should help.

PS. Similar problems are with kurtnoise13 libaften.dll build.

raquete

29th September 2007, 17:58

For now uncheck SSE SSE2 and SSE3 check boxes it should help.
working perfectly! :cool:

now a request for next version if you don't mind:
with 0.7 version i have to change to 1024x768 pixels.
is possible "back" to 800x600 pixels?

thanks sooo much.

wisodev

29th September 2007, 18:03

working perfectly! :cool:

now a request for next version if you don't mind:
with 0.7 version i have to change to 1024x768 pixels.
is possible "back" to 800x600 pixels?

thanks sooo much.

It will be hard ;). I added new controls to window in current release so I need to redesign placement of this controls and/or remove some of them. Any suggestions?

raquete

29th September 2007, 18:10

suggestions?
...don't remove anything please,only redesign.
:thanks:

wisodev

29th September 2007, 20:01

suggestions?
...don't remove anything please,only redesign.
:thanks:

OK. I redesigned the main dialog.

Version 0.4 of EncWAVtoAC3

http://img179.imageshack.us/img179/3588/mainwndbigqv7.th.png (http://img179.imageshack.us/my.php?image=mainwndbigqv7.png)

Version 0.8 of EncWAVtoAC3

http://img408.imageshack.us/img408/9462/encwavtoac308testen6.th.jpg (http://img408.imageshack.us/my.php?image=encwavtoac308testen6.jpg)

Version 0.8 of EncWAVtoAC3 (Desktop resolution: 800x600 Pixels)

http://img209.imageshack.us/img209/5945/encwavtoac308test800x60tf2.th.jpg (http://img209.imageshack.us/my.php?image=encwavtoac308test800x60tf2.jpg)

Mr_Odwin

5th October 2007, 14:00

My app, FAVC, feeds Aften through wavi (i.e. an avisynth script).

I've had some reports from users that using DirectShowSource on mkv files with 6 channel AAC audio leads to an Aften encoding that has the wrong channel order. It was my understanding that using DirectShowSource for audio would always give the correct order for Aften. Is this not the case?

Is it more likely that the original AAC file has the wrong channel mapping? Or, in general should I be reordering channels from AAC audio in Directshowsource to feed to Aften?

tebasuna51

5th October 2007, 16:35

I've had some reports from users that using DirectShowSource on mkv files with 6 channel AAC audio leads to an Aften encoding that has the wrong channel order. It was my understanding that using DirectShowSource for audio would always give the correct order for Aften. Is this not the case?
Say DirectShow is say nothing. Each user can have a distinct preferred (high merit) filter to decode AAC. With ffdshow or CoreAAC the output is correct.
Is it more likely that the original AAC file has the wrong channel mapping?
Yes, maybe is the problem. There are many tools with buggy aac channel mapping output, for instance: ffmpeg, Nero Burning Room (Encode Files...), ...
Or, in general should I be reordering channels from AAC audio in Directshowsource to feed to Aften?
Never, the output from DirectShow must be correct: the standard uncompressed wav order FL-FR-C-LFE-BL-BR

surfer63

7th October 2007, 12:21

Hi,

I'm on MacOsx and trying to compile aften 0.08.
I use the cmake .., which runs succesfully. However, the make step ends in error during the link fase.
Linking C executable aften
/usr/bin/ld: Undefined symbols:
_expstr_set_bits
_a52_window
collect2: ld returned 1 exit status
make[2]: *** [aften] Error 1
make[1]: *** [CMakeFiles/aften_exe.dir/all] Error 2
make: *** [all] Error 2

I'm not a developer/programmer, only a compiler.
I've searched the web but the only thing relevant (I think) was this post (http://gcc.gnu.org/ml/gcc/2005-06/msg00199.html).
As mentioned, I'm not a programmer so I don't know what to change.
Anyone can help me with this?

DarkAvenger

11th October 2007, 04:47

@surfer63
Could you run a "make clean" and then a "make VERBOSE=1" and then mail me the complete output?

@raquete

What kind of CPU do you have? Does using aften commandline work for you, even if you don't disable simd support?

wisodev

11th October 2007, 19:14

@raquete

What kind of CPU do you have? Does using aften commandline work for you, even if you don't disable simd support?

Hi,

I have fixed the crush problem when using my builds (actually there is one problem with libaften.dll build by Kurtnoise13 when used on system without SSE3 but Kurtnoise13 aften.exe build works perfectly) and released updated binaries (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=544535)! My aften.exe and libaften.dll builds are now working without any problems.

I made mistake by enabling SSE3 support for SSE version so when running on system with no SSE3 support there where crushes.

Sorry for the trouble.

wisodev

surfer63

11th October 2007, 22:09

@DarkAvenger

The complete output after make clean and make verbose=1 can't be copied completely in a post. So I will send it to you in a private mail (from this forum)

madshi

12th October 2007, 08:32

I have fixed the crush problem when using my builds (actually there is one problem with libaften.dll build by Kurtnoise13 when used on system without SSE3 but Kurtnoise13 aften.exe build works perfectly) and released updated binaries (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=544535)! My aften.exe and libaften.dll builds are now working without any problems.
Thank you for the updated binaries! Two little questions:

(1) Is there a specific reason why the libaften.dll is much bigger than the aften.exe? Shouldn't it be the other way round in theory?

(2) Those different builds with SSE(1,2,3) : Which build should I distribute with my software if I don't know if SSE will be available or not? Why are there different builds in the first place? Wouldn't it make more sense to have only one build which internally switches between different branches, depending on what the current CPU supports?

Thanks!

wisodev

12th October 2007, 09:23

Thank you for the updated binaries! Two little questions:

(1) Is there a specific reason why the libaften.dll is much bigger than the aften.exe? Shouldn't it be the other way round in theory?

(2) Those different builds with SSE(1,2,3) : Which build should I distribute with my software if I don't know if SSE will be available or not? Why are there different builds in the first place? Wouldn't it make more sense to have only one build which internally switches between different branches, depending on what the current CPU supports?

Thanks!

(1) Actually it's opposite the aften.exe is bigger then libaften.dll. I'm talking about aften-0.0.8-icl10 release (this is recommended build).

E.g.
aften_x86\aften.exe - 281 KB
libaftendll_x86\libaften.dll - 233 KB

You only need libaften.dll from libaftendll_* directory. The other files are needed when you link your program dynamically with libaften.dll. The aften.exe is there to test libaften.dll (this exe is linked dynamically with libaften.dll and I use it also for PGO optimizations when building with Intel C++ Compiler ).

(2) I know it's confusing but I had earlier in this thread explained why I do it this way. The aften_x86_SSE, aften_x86_SSE2 and aften_x86_SSE3 builds (and respectively the libaften.dll builds) have been built with special compiler switches that enable some optimization for newer CPUs and will not run on CPUs without specific instruction support (e.g. aften_x86_SSE3 build will not run on machine without SSE3 support). This builds are bit faster (not on all machines but on my they are) then aften_x86 builds. This also applies to *_AMD64 builds.

So you should use aften_x86 and libaftendll_x86 builds (or respectively aften_AMD64 and libaftendll_AMD64). This are universal binaries for Win32 (Win64) machines. They have built in MMX, SSE, SSE2 and SSE3 optimizations but are using them only when are supported by CPU.

wisodev

madshi

12th October 2007, 09:39

(1) Actually it's opposite the aften.exe is bigger then libaften.dll. I'm talking about aften-0.0.8-icl10 release (this is recommended build).

E.g.
aften_x86\aften.exe - 281 KB
libaftendll_x86\libaften.dll - 233 KB

You only need libaften.dll from libaftendll_* directory. The other files are needed when you link your program dynamically with libaften.dll. The aften.exe is there to test libaften.dll (this exe is linked dynamically with libaften.dll and I use it also for PGO optimizations when building with Intel C++ Compiler ).

(2) I know it's confusing but I had earlier in this thread explained why I do it this way. The aften_x86_SSE, aften_x86_SSE2 and aften_x86_SSE3 builds (and respectively the libaften.dll builds) have been built with special compiler switches that enable some optimization for newer CPUs and will not run on CPUs without specific instruction support (e.g. aften_x86_SSE3 build will not run on machine without SSE3 support). This builds are bit faster (not on all machines but on my they are) then aften_x86 builds. This also applies to *_AMD64 builds.

So you should use aften_x86 and libaftendll_x86 builds (or respectively aften_AMD64 and libaftendll_AMD64). This are universal binaries for Win32 (Win64) machines. They have built in MMX, SSE, SSE2 and SSE3 optimizations but are using them only when are supported by CPU.
Thank you! :)

DarkAvenger

12th October 2007, 14:28

@surfer63

I looked thorugh the output and I don't understand why you get the error. Either your version of gcc (could you give me output of gcc -v) or binutils seems to be buggy.

Could you test whether commenting out

TEST_COMPILER_VISIBILITY()

in the CMakeLists.txt helps? Do you by chance have some older version of aften installed?

madshi

12th October 2007, 16:03

I think there's a bug in aften.c:

if(!opts.pad_start) {

[...] // code adds padding here

}
Or am I missing/misunderstanding something?

tebasuna51

12th October 2007, 16:48

Or am I missing/misunderstanding something?
Isn't a bug,
[-pad #] Start-of-stream padding
The AC-3 format uses an overlap/add cycle for encoding
each block. By default, Aften pads the delay buffer
with a block of silence to avoid inaccurate encoding
of the first frame of audio. If this behavior is not
wanted, it can be disabled. The pad value can be a
1 (default) to use padding or 0 to not use padding.

Each frame uses the last 256 samples from precedent frame to encode the actual frame (time -> frequency domain). This is a problem for first frame, there are two methods:

With -pad 1 (default), the first 256 samples (delay buffer) are already filled with silence (and introduce a 5.33 ms delay if 48 KHz.) and the real samples are encoded properly.

With -pad 0 [if(!opts.pad_start)] the first 256 samples are filled with real samples, without delay but with something like a fade-in in first 5.33 ms.

madshi

12th October 2007, 17:57

With -pad 1 (default), the first 256 samples (delay buffer) are already filled with silence (and introduce a 5.33 ms delay if 48 KHz.) and the real samples are encoded properly.

With -pad 0 [if(!opts.pad_start)] the first 256 samples are filled with real samples, without delay but with something like a fade-in in first 5.33 ms.
I don't see that in the source code. When "opts.pad_start" is 0, there is an additional "aften_encode_frame" call in the source code, where the first 1280 samples are set to zero and only the last 256 samples are real samples. When "opts.pad_start" is 1, there is no padding at all, as far as I can see from the source code.

Or is there some magic going on behind the scenes? But how can an additional "aften_encode_frame" call result in less padding?

:confused:

I think the code should read "if(opts.pad_start)". But well, maybe I'm embarassing myself right now... :o

surfer63

12th October 2007, 18:12

@DarkAvenger

I have been working on the "not-compiling" of 0.08 for quite some weeks now. Some of my "fellow" (more clever) programmers found the solution.
export CFLAGS=-fno-common
cmake -DSHARED=1 ..
make
sudo make install

Apparently global variables that are defined in different object files need to be initialised on the Mac. The no-common option will initialise these variables to zero.
Sorry for taking your time and than solving it self.

DarkAvenger

12th October 2007, 18:44

@surfer63

Ah, thx for the hint. I remember now I had this problem once with OpenAL. A shame that I forgot about it...

Could you try this patch:

Index: libaften/exponent.c
===================================================================
--- libaften/exponent.c (Revision 563)
+++ libaften/exponent.c (Arbeitskopie)
@@ -29,7 +29,7 @@

#include "cpu_caps.h"

-uint16_t expstr_set_bits[6][256];
+uint16_t expstr_set_bits[6][256] = {{0}};

static void process_exponents(A52ThreadContext *tctx);

Index: libaften/window.c
===================================================================
--- libaften/window.c (Revision 563)
+++ libaften/window.c (Arbeitskopie)
@@ -33,7 +33,7 @@
#include "cpu_caps.h"

-ALIGN16(FLOAT) a52_window[512];
+ALIGN16(FLOAT) a52_window[512] = {0};

static void
apply_a52_window(FLOAT *samples)

Please delete CMakeCache.txt, don't set -fno-common, run cmake and make, and report back whether it worked. Thx!

surfer63

12th October 2007, 19:06

@DarkAvenger.

The patch does work for a cmake ..

However, I like to have a dynamic library. When I use "cmake -DSHARED=1 .." I get the following error.

Linking C shared library libaften.dylib
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
CMakeFiles/aften.dir/libaften/a52enc.o private external definition of common _nexpgrptab (size 3072)
/usr/bin/libtool: internal link edit command failed
make[2]: *** [libaften.0.0.8.dylib] Error 1
make[1]: *** [CMakeFiles/aften.dir/all] Error 2
make: *** [all] Error 2

When reapplying the export CFLAGS=-fno-common, the cmake -DSHARED=1 .. and make works again.

DarkAvenger

12th October 2007, 21:55

Well, if you look at the error message, you'll see it complains about another variable.

Try putting this patch on top. I wonder why no other mac user complained before...

Index: libaften/a52enc.c
===================================================================
--- libaften/a52enc.c (Revision 563)
+++ libaften/a52enc.c (Arbeitskopie)
@@ -46,7 +46,7 @@
* LUT for number of exponent groups present.
* expsizetab[exponent strategy][number of coefficients]
*/
-int nexpgrptab[3][256];
+int nexpgrptab[3][256] = {{0}};

/**
* Pre-defined sets of exponent strategies. A strategy set is selected for

surfer63

13th October 2007, 08:41

@DarkAvenger

This second patch does the job. Aften compiles/builds fine now, also when building a shared library. I will start using/testing.

Thanks a lot for your help and good work!

DarkAvenger

13th October 2007, 16:10

Thx, commited.

@madshi

I think you are right. I don't understand it, as well. Justin?

jruggle

13th October 2007, 16:57

I don't see that in the source code. When "opts.pad_start" is 0, there is an additional "aften_encode_frame" call in the source code, where the first 1280 samples are set to zero and only the last 256 samples are real samples. When "opts.pad_start" is 1, there is no padding at all, as far as I can see from the source code.

Or is there some magic going on behind the scenes? But how can an additional "aften_encode_frame" call result in less padding?

:confused:

I think the code should read "if(opts.pad_start)". But well, maybe I'm embarassing myself right now... :o

I'll try to explain the process better.

The encoder reads 1536 samples (1 frame) at a time, but due to the overlap/add process it needs 256 samples from the previous frame. At the start of encoding, those "delay" samples are just initialized to zero. This is the standard way of doing things, but will end up delaying the decoded output. When the option to get rid of the delay is turned on, Aften reads 256 input samples to prime the delay instead of zeros. That eliminates the decoding delay. The call to encode_frame() is really only used to get those samples into the delay buffer. The resulting frame is not actually written to the file output.

Hope that helps.

jruggle

13th October 2007, 17:05

Thx, commited.

@madshi

I think you are right. I don't understand it, as well. Justin?

I don't fully understand linking, and even less with shared libs. But yeah, it just looks like gcc on mac complains about uninitialized globals. I always thought they were initialized to zero by default, but maybe that's just the static ones...?

FFmpeg probably has 50+ of these. I wonder why they don't have the same complaints... Maybe something in the build system turns on the right compiler/linker flags?

DarkAvenger

13th October 2007, 17:33

Oh, I was rather referring to the padding issue. ;) [Edit] Forget about it, I haven't seen your first post, but now I did.

Regarding the linker: It seems to be some feature of the macho binary format or alike. Yes, it can be avoided by compiler flags (-fno-common) or linker flag (something with single module) or by explicitly initializing as far as I learnt. I am not sure what would be the right way. According to what I read on a mailing list, the linker flag should be the right way, but well... I think fixes in C code are more stable than forcing compiler/linker flags.

madshi

13th October 2007, 20:56

I'll try to explain the process better.

The encoder reads 1536 samples (1 frame) at a time, but due to the overlap/add process it needs 256 samples from the previous frame. At the start of encoding, those "delay" samples are just initialized to zero. This is the standard way of doing things, but will end up delaying the decoded output. When the option to get rid of the delay is turned on, Aften reads 256 input samples to prime the delay instead of zeros. That eliminates the decoding delay. The call to encode_frame() is really only used to get those samples into the delay buffer. The resulting frame is not actually written to the file output.

Hope that helps.
Thank you for the explanation! But I'm still a bit confused. For me the code in "aften.c" reads like this:

pad 0:
encode_frame(1280 zero samples + 256 real samples);
repeat
encode_frame(1536 real samples);
until stream_end;

pad 1:
repeat
encode_frame(1536 real samples);
until stream_end;

Do I read that correctly? Here's what I have problems with:

(1) With "pad 0": How does the encoder know that the "1280+256" frame is only meant to initialize the delay buffer and not meant to be output?

(2) With "pad 1": How does the encoder know that the first encode_frame call (which has 1536 real samples in it) is meant to be output?

If your explanation is correct (which it surely is) the encoder behaves differently with "pad 0" and "pad 1". With "pad 0" the encoder just eats the first frame and doesn't output it. With "pad 1" the first frame is output. I just don't see how the encoder can differ between "pad 0" and "pad 1" because I don't see anything in the code where the encoder is told which pad setting is used!

DarkAvenger

13th October 2007, 21:29

The mdct keeps a buffer of the last 256 samples by itself, thus it works as explained.

reg. (1) The encoder doesn't know it. But the front-end doesn't write the encoded frame. In your pseudo code you are missing the write_encoded_frame, which only happens in the loop. I also haven't noticed this until Justin explained it...

madshi

13th October 2007, 22:20

madshi

13th October 2007, 22:28

@Justin, I've just proven that the padding option doesn't work correctly.

Here's what I've done:

(1) Small sample WAV file encoded with pad 0 and with pad 1 by using aften.exe.
(2) Decoded the files through GraphEdit -> AC3Filter -> Dump.
(3) Compared PCM data of decoded files to original WAV file.

pad 0: The audio data is delayed by 1535 samples
pad 1: The audio data is delayed by 255 samples

Don't know why the delay is 1535 instead of 1536 (and 255 instead of 256). Maybe AC3Filter eats the first sample. But it's definitely true that with the "pad 0" option there is more padding and bigger audio delay than with "pad 1" option.

madshi

13th October 2007, 22:34

I think I've earned me another question: :)

aften.exe always converts any input samples into float before feeding them into the encoder. However, the encoder itself does support integer samples. I've compared the AC3 frames when feeding the encoder with either integer samples or (converted) float samples - and the output differs! So I'm wondering what the best solution is for audio quality. Should I feed the encoder with the integer samples in their original form? Or should I convert to float, just as aften.exe does?

Thanks!

madshi

13th October 2007, 22:53

jruggle

13th October 2007, 23:43

So I'm wondering what the best solution is for audio quality. Should I feed the encoder with the integer samples in their original form? Or should I convert to float, just as aften.exe does?

Honestly, you can do it either way. It was easier for the Aften program to do conversion outside of libaften because it allows for more flexibility with input formats. But libaften also has built-in conversion capability for convenience. Right now they both do the same exact thing, so you really shouldn't see any differences unless there is a bug somewhere.

jruggle

14th October 2007, 00:01

More information about the padding bug:

With Aften 0.0.7 the "pad 0" option works as intended! But with Aften 0.0.8 it doesn't (using wisodev's builds). So it seems that 0.0.8 introduced this bug.

Maybe with Aften 0.0.7 the first "encode_frame" call doesn't return an output length of 0 while it does with Aften 0.0.8? That would explain the bug.

Wow, you're right.

I also found a possibly related bug... Aften crashes with segfault on Linux when encoding mono wav files using multiple threads...unless I turn padding off...but it still doesn't take out the padding.

I'll see if I can figure it out.

jruggle

14th October 2007, 00:35

Wow, you're right.

I also found a possibly related bug... Aften crashes with segfault on Linux when encoding mono wav files using multiple threads...unless I turn padding off...but it still doesn't take out the padding.

I'll see if I can figure it out.
The issue is definitely related to threading. "-pad 0" should work correctly if you use "-threads 1". And I'll keep working on it...

madshi

14th October 2007, 08:09

The issue is definitely related to threading. "-pad 0" should work correctly if you use "-threads 1". And I'll keep working on it...
Thanks.

Is it intentional that the first two encode_frame calls return an output length of 0? I have to call encode_frame with the input buffer set to NULL twice after the encoding is done to get a full size AC3 file. Furthermore if I don't call encode_frame(NULL) twice before calling aften_encode_close at the end of decoding, the call to aften_encode_close stalls.

madshi

14th October 2007, 08:15

Honestly, you can do it either way. It was easier for the Aften program to do conversion outside of libaften because it allows for more flexibility with input formats. But libaften also has built-in conversion capability for convenience. Right now they both do the same exact thing, so you really shouldn't see any differences unless there is a bug somewhere.
Thanks for the reply. You're right. I've double checked and the output is identical. I must have messed up my earlier test somehow.

DarkAvenger

14th October 2007, 08:15

Thanks.

Is it intentional that the first two encode_frame calls return an output length of 0? I have to call encode_frame with the input buffer set to NULL twice after the encoding is done to get a full size AC3 file. Furthermore if I don't call encode_frame(NULL) twice before calling aften_encode_close at the end of decoding, the call to aften_encode_close stalls.

[Edit]This is expected if threading (with 2 threads) is activated. I guess we should explain this behaviour in some FAQ...

But I now also know why padding doesn't work properly with 0.0.8: Due to threading the first calls won't return anything anyway, so in fact when padding is activated one should throw away the first frame which actually comes back from the encoder...and this this happens now in the main loop...

I just commited a fix for this. I haven't checked the issue with mono input, though.

madshi

14th October 2007, 14:16

This is expected if threading (with 2 threads) is activated. I guess we should explain this behaviour in some FAQ...
Thanks for your reply. Wouldn't it make sense to add code to "aften_encode_close" to make sure that it doesn't stall? IMHO an API should never stall. It may fail. If all else fails it might even crash. But it should never stall IMHO. Because I (as an libAften user) can handle failing APIs, I can even handle crashing APIs, but once an API stalls every hope of a graceful error handling is lost. Maybe you could just add two encode_frame(NULL) calls in the beginning of aften_encode_close if necessary?

But I now also know why padding doesn't work properly with 0.0.8: Due to threading the first calls won't return anything anyway, so in fact when padding is activated one should throw away the first frame which actually comes back from the encoder...and this this happens now in the main loop...
That makes a lot of sense. Does the first frame also need to be thrown away if the "-threads 1" option is used?

Thank you!! :)