Aften 0.0.8 is out

[Kurtnoise]

Just found this at HA.org...and it sounds promizing. :)

Aften (http://sourceforge.net/projects/aften) is a simple, open-source, A/52 (AC-3) audio encoder.

The name, Aften, is an acronym for:
A / Fifty-Two ENcoder
It is also Danish and Norwegian for 'evening'.

This program started as a simple cutting-out of the AC3 encoder from FFmpeg, but then I reworked the structure of the encoder a bit. Most of the basic code is still the same though. Here are some of the things I've changed so far.

* Implemented my own wav reader and bitwise file writer
* Converted the fixed-point algorithms to floating-point
* Rearranged the methods and structures
* Added stereo rematrixing (mid/side)
* Added short block MDCT and block switching
* Added VBR encoding mode

Future Plans

* Variable bandwidth
* Channel coupling



Changelog of the last release:
* fixed piped input from FFmpeg
* added support for MPEG channel order remapping
* restructured audio input. enables raw pcm file support.
* bugfixes in MMX/SSE2 code
* stack align hack for x86 MinGW with threads
* API changes
* SIMD and threads usage is shown and is configurable
* screen output gets updated every 200ms to reduce load
* SIMD detection changed to compiler-independent inline assembly, thus nasm/yasm not needed anymore


So, I've made a compile for win32 OS and I added pipeline & 2 switches for CBR and VBR Mode. Could be great if somebody can test multichannel encoding also.

Command Line example for VBR :
aften -q 300 input.wav output.ac3

Command Line example for CBR :
aften -b 256 input.wav output.ac3

Command Line example with pipeline :
aften -q 320 - output.ac3

Wisodev's builds :: http://win32builds.sourceforge.net/aften/index.html
For whose who prefer GUIs instead of command lines, I've made a small one (http://kurtnoise.free.fr/index.php?dir=Aften/&file=AftenGUI-1.4.zip).

[vmesquita]

I've tested with a 6-channel WAV produced by BeSweet from an AC3 file and it worked. However I can't tell if the channels were mapped correctly because I don't have a good home theater... :rolleyes:

[vmesquita]

Did a test using A test file and AC3Filter, and channel mapping is incorrect (relating to BeSweet output). :(

EDIT:
I've tried to fix this in BeSweet using this:

D:\Temp\besweet>BeSweet.exe -core( -input "D:\Temp\besweet\6ch.ac3" -output "D:\Temp\besweet\6ch.wav" -6chwav ) -azid( -o l,c,r,sl,sr,lfe)

However the switch doesn't seem to be working, or maybe the sintax is wrong.

[Kurtnoise]

Could you test this sample (http://kurtnoise.free.fr/Sample.ac3) please ?

This is not made with BeSweet. It's just for testing channel mapping.

[tebasuna51]

Could you test this sample (http://kurtnoise.free.fr/Sample.ac3) please ?

This is not made with BeSweet. It's just for testing channel mapping.
The sample seems ok.

[SeeMoreDigital]

Or you could try this sample (http://82.10.220.174/51_Test_Encodes/AV_Setup_Tests/AC3_6Ch_'Speaker_Test'.7z) :)

[danpos]

Or you could try this sample (http://82.10.220.174/51_Test_Encodes/AV_Setup_Tests/AC3_6Ch_'Speaker_Test'.7z) :)

Hi there! VMesquita had tried your sample out already (I sent it to him ;) ). BTW, it's a very usefull ac3 5.1 sample for channels mapping tests. Thanks for share it.

See you,

[tebasuna51]

@Kurtnoise
If you want improve the aften encoder I have two suggestions

1) To make a correct channel remapping we can replace the Int to Float routine at aften.c (line 125):
for(i=0; i<A52_FRAME_SIZE*wf.channels; i++) {
if(i < nr*wf.channels)
fwav[i] = wav[i] / 32768.0;
else
fwav[i] = 0.0;
}
With this new one:
if(wf.channels == 6) {
for(i=0; i<A52_FRAME_SIZE*6; i+=6) {
if(i < nr*6) {
fwav[i] = wav[i] / 32768.0; // FL
fwav[i+1] = wav[i+2] / 32768.0; // C
fwav[i+2] = wav[i+1] / 32768.0; // FR
fwav[i+3] = wav[i+4] / 32768.0; // SL
fwav[i+4] = wav[i+5] / 32768.0; // SR
fwav[i+5] = wav[i+3] / 32768.0; // LFE
}
else
for(j=0; j<6; j++) fwav[i+j] = 0.0;
}
}
else {
for(i=0; i<A52_FRAME_SIZE*wf.channels; i++) {
if(i < nr*wf.channels)
fwav[i] = wav[i] / 32768.0;
else
fwav[i] = 0.0;
}
}


2) New parameters, valid values and default, to be passed to output_frame_header (a52enc.c):

-c 0,1,2 Default: 0 (-3,-4.5,-6 dB) Center Mix Level
-s 0,1,2 Default: 0 (-3,-6,0 dB) Surround Mix Level
-d 0,1,2 Default: 0 (Ignored,Not,Yes) Dolby Surround Mode
-n 0..31 Default: 31 (-0..-31 dB) Dialogue normalization

[vmesquita]

@tebasuna51
Tested the mod and now the channels are being correctly mapped for BeSweet output :D

[Kurtnoise]

1) To make a correct channel remapping we can replace the Int to Float routine at aften.c
Yep...done (http://kurtnoise.free.fr/misc/aften_20060709.zip). I'll try to make a build with ICL compiler later. Maybe this should improve the speed.


2) New parameters, valid values and default, to be passed to output_frame_header (a52enc.c):

-c 0,1,2 Default: 0 (-3,-4.5,-6 dB) Center Mix Level
-s 0,1,2 Default: 0 (-3,-6,0 dB) Surround Mix Level
-d 0,1,2 Default: 0 (Ignored,Not,Yes) Dolby Surround Mode
-n 0..31 Default: 31 (-0..-31 dB) Dialogue normalization
mmh...Isn't it more useful for decoder side instead of encoder ?

[vmesquita]

I did a modification to add 6-WAV support. This can be useful because sometimes we want to change AC3 duration (for framerate conversions) and SoundStretch only support Mono WAVs, while BeSweet built-in SoundTouch doesn't work well in my experience. You can download sources and binary here:
http://www.vmesquita.com/files/aften_6wav.zip

[tebasuna51]

mmh...Isn't it more useful for decoder side instead of encoder ?
Maybe for Center Mix Level and Surround Mix Level, but this values are taken from BSI when the decoder isn't instructed with another values. At least we can put the default values proposed by Dolby:
// if ((s->acmod & 0x01) && s->acmod != 0x01) bitwriter_writebits(&s->bw, 2, 1); /* XXX -4.5 dB */
if ((s->acmod & 0x01) && s->acmod != 0x01) bitwriter_writebits(&s->bw, 2, 0); // -3 dB (Dolby default)
// if (s->acmod & 0x04) bitwriter_writebits(&s->bw, 2, 1); /* XXX -6 dB */
if (s->acmod & 0x04) bitwriter_writebits(&s->bw, 2, 0); // -3 dB (Dolby default)

The Dolby Surround Mode flag is claimed by many users because, when is played by a hardware decoder, can switch automatically to DPL mode.

The Dialogue Normalization is a important parameter in ac3 encode, you can see:
GUIDE: How To Properly Encode Dolby Digital Audio (AC3) (http://forum.doom9.org/showthread.php?t=56020)

[Rockaria]

Good to see the Aften is having the correct AC3 channel order from the default wav-format order.
I believe the AC3 decoders are also responsible to restore the original wav-format channel order to play or transcode.
However :
The Dolby Surround Mode flag is claimed by many users because, when is played by a hardware decoder, can switch automatically to DPL mode.
My h/w decoders(& probably many other decoders too) are auto/stereo/surround decoding mode manually selectable.
So as far as the mode is set to auto/surround, it decodes depending on the detected actual stream : AC3, DTS... | 5.1, 2.1,.., DPL II..
For an example, when I set the ac3 out mode in the FFDShow and change the mixer mode, it decodes all the 2.0 ch modes(DPL II, 2.0....) to DPL II mode(forced) automatically.

Probably only when the DD 2.0 contains the DPL mix, the ds meta info is used for some old decoders to be automatic to switch between DPL & STEREO mode.

[tebasuna51]

At least in this thread: BeSweet + AC3Enc: Tag generated 2.0 AC3 as "surround" if downmix was used (http://forum.doom9.org/showthread.php?t=101890) is claimed the Dolby Surround Mode flag.

I think is easy to implement, without waste resources, and why not?
I make the necessary (I hope) mods to include the four parameters in Aften_mod_sources (http://www.mytempdir.com/794544)

All parameters are optional, also when use:
aften input.wav output.ac3
is encoded CBR with 448 Kb/s for 6 channel wav or 192 Kb/s for other number of channels.

Please, if anybody can compile this sources (I don't have the appropriate compiler) I can test the result. Thanks.

Edit: @vmesquita, I can't access your links. Please use http://www.mytempdir.com/

[Rockaria]

Indeed, Dolby's doc contains some more :

On most equipment, the consumer can, through the product's user interface, choose the appropriate downmix for their playback system. Certain metadata parameters allow the engineer to select how the stereo downmix is constructed and which downmix is preferred, although the Lt/Rt downmix is usually the default. The downmix modes(preferred/mixed) : Lt/Rt(Yes above : DPL), Lo/Ro(No : simple stereo). If we count the DPL II, I don't know how important this tag is any more.

But I agree, reserving & setting the correct options are not wasting the space and certainly useful for certain decoders or any other uses..

[vmesquita]

@tebasuna51

EDIT:
I have merged the 6 wav mod with the mods you posted, added the usage to when aften is called with no arguments, and fixed a little typo in your mod. Binary and source:
http://www.mytempdir.com/794693

(I didn't test, I hope it's working correctly)

[tebasuna51]

@vmesquita
Thanks, but in your .rar the aften.exe is missing.

[Kurtnoise]

Allright...I patched tebasuna stuff and merged it with the 0.01 version.

Thanks to some improvements posted on the doom9 forum, I have done some work on Aften (http://jbr.homelinux.org/aften) today and released a new version.

http://jbr.homelinux.org/aften/aften-0.01.tar.bz2

* simple configure script
* piped input and output
* corrected 6-channel mapping
* corrected defaults for mix levels
* commandline options
* quiet mode (no console output)
* per-frame or average statistics
* big-endian support (not tested though)

I had PMed Justin to this thread. ;) Download here (http://kurtnoise.free.fr/misc/aften-0.01.zip).

[vmesquita]

@tebasuna51
Sorry, here is the full package:
http://www.mytempdir.com/795181

[tebasuna51]

@vmesquita
Thanks for your job, but maybe there are a problem because your aften.exe never finish to encode. Stoped with Ctrl-C, the first part is ok and after a long silence. The parameters are taken ok.

@kurtnoise
Your new version works fine for me. Thanks for the patch.

In firsts tests I detected:
Aften accept any wav type, but only work with 16 bit Int wav's. With 24,32 bit Int or float the resultant ac3 is unusable. With 8 bit Int Aften abort.
Accept also WAVE_FORMAT_EXTENSIBLE (16 bit Int), then the faad output can be used directly with Aften.

Tested also the pipe issue with AviSynth based Bepipe and BeHappy.

Edit: More tests (not important because isn't frequently used)

wav_3chan, acmod used 3 (L,C,R) needed remap [0,2,1], the acmod 4 (L,R,S) is not accesible (remap not needed)

wav_4chan, acmod used 6 (L,R,SL,SR) remap not needed, the acmod 5 (L,C,R,S) is not accesible (needed remap [0,2,1,3])

wav_5chan, acmod used 7 (L,C,R,SL,SR) needed remap [0,2,1,3,4] (without LFE).

Edit 2: Work also with wav > 4GB
Test with wav 4.2 GB, 6 chan, 130 min. encoded in 12 min. in a P IV 2.4GHz

[vmesquita]

@tebasuna51
Thanks for the test, I'll check this. I have tested with a small 6h wav and Six Waves and it seemed to work fine (with no need for ^C). I'll run more testes to try to reproduce the issue.

[tebasuna51]

After the test I think Aften is the best free ac3 encoder.

I want compare the options with the old reference encoder Sonic Foundry SoftEncode (in speed Aften is clearly the winner, Softencode need hours to encode a 6 chan 130 min long):

Audio service configuration
There are some more options in SoftEncode
-Audio coding mode: mode 4 (L,R,S) and mode 5 (L,C,R,S)
-Bit stream mode: other than Main audio service. Complete main
-Save frames in Intel byte order
I don't need this options.

Bit Stream
-Copyright bit
-Original bit stream
-Audio production information
Default is ok for me.

Preprocessing
-Input filtering->Digital deemphasis
-Input filtering->DC high-pass filter
-Input filtering->Bandwidth low-pass filter
-Input filtering->LFE low-pass filter
-Surround channel processing->90 degree phase shift
-Surround channel processing->3 dB atenuation
All this utilities can be applied to the wav input before the encoder process.
-Dynamic range compression (DRC):
This info must be generated be the encoder and, I think, is the more important difference between free and commercial encoders at this moment.

Conclusions
To improve Aften encoder there are two priorities for me:
-Generate DRC info. I know is not easy, and out of my knowledge, but I think is important.
-Accept 32 bit Int and Float wav's. If we have a more precise source we lose quality converting to 16 bit Int to be accepted by Aften. I can collaborate with this point if needed.

Questions
About ac3 VBR. Is compatible with avi container and DVD authoring programs?

@Kurtnoise. What is the difference between aften.exe and aften_g.exe in your last pack?

[Kurtnoise]

What is the difference between aften.exe and aften_g.exe in your last pack?
Honestly, I don't know...I tested both and compared bits-to-bits each results : this is the same. I hope that Justin can access as soon as possible in doom9 forum to give some answers.

Otherwise, you can post some notes here (http://www.hydrogenaudio.org/forums/index.php?showtopic=46088&pid=410652&st=0&#entry410652).

About compatibility for AVI container : I think this is the same thing like mp3 vbr.

Only worries I have come from vbr mode. Some decoders aren't able to decode/play properly this kind of files (at least on windows). With some Dshow filters like AC3 parser + AC3 filter, it works fine though.

[raquete]

@ Kurtnoise13
have a new aften version in the homepage
http://jbr.homelinux.org/aften/

thanks :goodpost: :goodpost:

@ tebasuna51
After the test I think Aften is the best free ac3 encoder.
good to know. ;)

ot: :stupid:
i don't know command lines.can you(anyone) please do one single "how to" ?

[Kurtnoise]

iirc, there are no new things in the 0.02 version compared to my 0.01 build. I'll check later because I can't access to the official website right now.

For a "How to", I gave some commands in the 1st post but I'll try to integrate this into BeLight asap.

[Mug Funky]

this sounds exciting... i missed the thread for a few days, but now i'll be checking regularly :)

About ac3 VBR. Is compatible with avi container and DVD authoring programs?

DVDMaestro spits out VBR (it requires CBR for the duration of each title. DVD in general is probably the same).

avi can probably handle it insofar as it handles VBR mp3 etc (kinda poorly).

about DRC info - i'm sure looking at the source for a dynamics compressor will help :) don't worry too much about the attack/release times used, as i really don't like the ones used by commercial encoders anyway (attack times are way too long usually). just remember the attack should probably vary depending on how much compression is applied - i'm not sure how decoders handle applying the gain. do they do it per block or interpolate the per-block values? my guess is they just gain each block and let the 50% overlap handle it, in which case too sudden a change would give a very strange effect of volume going down in audible increments.

all that stuff is testable though...

k, i hope at least some of that made sense :)

[raquete]

I'll try to integrate this into BeLight asap.
;) will be wonderful,thanks so much.

[raquete]

@ Kurtnoise13
I can't access to the official website right now
me too.i'm trying to open the official website for 3 days. :(
something wrong?(maybe you know about or have news)

[Kurtnoise]

Seems to be ok now... :) So, I uploaded 0.02 (http://kurtnoise.free.fr/misc/aften-0.02.zip). As I said previously, there are nothing new except the name of some switches which are different.


Concerning this into BeLight, my first tests show that it doesn't work properly...:s and I don't know why. I'll check out when I'll have more time.

[Kurtnoise]

@Tebasuna :
"aften_g" is compiled with debugging symbols. The "g" refers to the gcc option "-g". This makes debugging easier (gdb will give the file, function, and line number of an error), but the binary is larger. The "aften" binary is the same as "aften_g", but the debugging symbols are stripped so the file is smaller.

All in all, for whose who prefer GUIs instead of command lines, I've made a small one (http://kurtnoise.free.fr/misc/AftenGUI-1.0.zip). Drag&Drop is enabled. You can also have some infos by clicking in the Input Files list (Duration, Sampling-Rate, Bitrate, Channels Number). aften.exe must be in the same folder. If you have some suggests, I'm open...;)

[raquete]

thank you so much for the Gui Kurtnoise13,you're very cool. :cool:

[raquete]

Kurtnoise13,
selecting the output as "E:/temp" or any other folder,the AftenGui is saving the files in the root of the drive choosed( E:/ )

[Ebobtron]

Kurtnoise13

using 0.02
I suddenly have found myself working on sound features in avsFilmCutter (http://forum.doom9.org/showthread.php?t=97438) and thought I would say thanks for the find and add my 2 cents.

I encoded a 2:21:29 clip and found the overall quality to be very poor.

I used all default settings and it sounded as if it was dropping bits or the buffer had under run. The time was reported at over 10 hours.

When used with a three minute clip at a CBR of 192,000 the times reported by the player were correct and the sound improved.

Seemed like there was junk in the stream, too. Data fields from the decoder ( AC3Filter ver 1.01a_rc5 ) keep jumping.

Both were 2 channel 16 bit waves at 48000 Hz.

Nice start, sure is easy to use.
Will keep watch.

Thanks again.

[Kurtnoise]

@Raquete : fixed (http://kurtnoise.free.fr/index.php?dir=Aften/&file=AftenGUI-1.1.zip)...

@Elbotron : yeah, as I said previously, files encoded with vbr mode have some issues during the decoding. an AC3 parser is needed. Or AC3 decoders need to be updated to support vbr...

For the moment, CBR mode is recommended.

[raquete]

thank you so much . :)

why the AftenGui is not in the first post of the thread?!!!

[jruggle]

Ok, I can finally reply! :) To answer a few questions...

aften_g is not really different from aften in any significant way. The "aften_g" executable has debugging symbols, where "aften" does not. The size of the binary is larger for aften_g, but it is useful in finding problems in the code.

DRC is something that will be tricky to add. I do wish I had access to a good reference encoder to compare with. Maybe getting some DVD's and making a simple parser would give some clues as to how to calculate it properly.

24/32/float wav files will be supported sometime soon. It won't be that hard...I just have to rework the API a bit.

Filtering...I agree with adding a filter for LFE and DC, but not for bandwidth. That is effectively taken care of by excluding the highest MDCT coefficients. The only advantage I can see is maybe a smoother transition band.

I'm sorry that the site was down for a few days...I was out-of-town and it seems a power flicker reset my web server.

VBR and containers: As mentioned by others, it can be done in AVI the same way as with MP3. Also, I just found a place in the spec where it implies that VBR should be supported in MPEG-TS. There are two sets of bitrate codes for the audio stream descriptor. One set is for exact bit rate, while the other is for bit rate upper limit. I have gotten VBR to "work" in avi, mpeg-ps, mpeg-ts, and matroska. Decoding support will probably still be very limited though. I am really hoping that DVD players will support it. I would guess yes since most of the manufacturers probably paid for a Dolby-certified decoder so they could put the logo on the player. :)

Thanks for the GUI kurtnoise13. I don't have Windows, so could someone post a screenshot somewhere? I'm just curious. :) I might have an old version of Aften I wrote in Java lying around on my computer somewhere. If so, I could easily write a cross-platform GUI for that. For the record, I don't care much for Java when it comes to mathematical stuff because of the lack of unsigned types and pointer control, but it's wonderful for quick-n-easy graphical interfaces...and card games ;).

If I forgot anything or there are any other questions, ask away.

-Justin

[jruggle]

If someone wants to test this in various decoders, here is an MPEG2-PS file with VBR AC3.

http://jbr.homelinux.org/aften/right_place.mpg

-Justin

[Mug Funky]

I am really hoping that DVD players will support it. I would guess yes since most of the manufacturers probably paid for a Dolby-certified decoder so they could put the logo on the player

well, that came with paying for the DVD logo... and DVD doesn't support VBR ac3. i'm sure one could hack a DVD to have VBR audio, but i doubt it'd play on anything at all. there are no authoring programs that support it, so one would have to use ifoedit or similar to place the VBR stream into the movie.

it'd be an interesting test though.

[raquete]

I don't have Windows, so could someone post a screenshot somewhere? I'm just curious.

http://img95.imageshack.us/img95/7818/kurtaftenguito3.png

welcome jruggle ;)

[Kurtnoise]

why the AftenGui is not in the first post of the thread?!!!
ok..done. :)

I don't have Windows, so could someone post a screenshot somewhere? I'm just curious.
Welcome on Doom9 Justin :) . Here is a screenshot (http://img215.imageshack.us/img215/1711/captureah1.png).(edit: oups, raquete is faster than me.) I plan to make a new GUI with GTK later...;)


Radiohead is good...:D Your mpg file works fine with mplayer and some other directshow players (MPC, TCMP).

[dimzon]

Hmm. A will add this encoder to BeHappy ASAP

ADD:
Some 128*96 logo variations ;)
http://img405.imageshack.us/img405/3250/aftenlogosmallzc7.png

http://img405.imageshack.us/img405/6537/aftenlogosmall1vl3.png

http://img76.imageshack.us/img76/3128/aftenlogosmall2vw1.png

[dimzon]

Now BeHappy support it ;)
http://img232.imageshack.us/img232/274/aftenam4.png

Warning! I have no time to test it so try and report

[tebasuna51]

@jruggle, welcome to the forum and thanks for your answers to my questions.

In your web I read:
"Future Plans
...
More testing & better support for multi-channel
..."
Then maybe are you interested in full remapping (not only for 6 chan), with something like that (aften.c, line 333):
// Correct Channel mapping for all ch streams
int remap = 0; // 0 not needed
if(status->acmod==3 || status->acmod==5 || status->acmod==7) {
remap = 1; // needed for this acmod
channelmap(ch) ((int []){ 0, 2, 1, 4, 5, 3 })[ch] // for 6 chan. (Syntax ??)
// { 0, 2, 1, 3, 4, x } // for < 6 chan.
if(wf.channels != 6) {
channelmap(3)=3;
channelmap(4)=4;
}
}
while(nr > 0) {
if(remap == 1) {
int j;
for(i=0; i<A52_FRAME_SIZE*wf.channels; i+=wf.channels) {
if(i < nr*wf.channels) {
for(j=0; j<wf.channels; j++) {
fwav[i+j] = wav[i+channelmap(j)] / 32768.0;
}
} else {
for(j=0; j<wf.channels; j++)
fwav[i+j] = 0.0;
}
}
} else {
...
Now work also for ac3 5.0 (without LFE)

[daphy]

Is there any Dolby EX support (with more than 6 channels) planed :)

[jruggle]

Is there any Dolby EX support (with more than 6 channels) planed :)
I don't know much about Dolby EX, but from what I gather on the website and from the specs, the extra rear-center information is matrixed into the left and right surround channels and is extracted by a Dolby EX capable decoder. The only thing the AC-3 format does in this regard is flag the stream as containing a Dolby EX stream. This can be done with the alternate bit stream syntax, which is not currently supported by Aften. I'll put that on my TODO list though.

-Justin

[jruggle]

@jruggle, welcome to the forum and thanks for your answers to my questions.

In your web I read:
"Future Plans
...
More testing & better support for multi-channel
..."
Then maybe are you interested in full remapping (not only for 6 chan), with something like that (aften.c, line 333):

Thank you. I definitely want to support both standard wav channel remapping and also wav_format_extensible. I'll try to get this done tomorrow or Saturday, along with 32/24/float wav support...otherwise it might not be for a week or two.

-Justin

[daphy]

I don't know much about Dolby EX, but from what I gather on the website and from the specs, the extra rear-center information is matrixed into the left and right surround channels and is extracted by a Dolby EX capable decoder. The only thing the AC-3 format does in this regard is flag the stream as containing a Dolby EX stream. This can be done with the alternate bit stream syntax, which is not currently supported by Aften. I'll put that on my TODO list though.

-Justin

Seams to me that Aften could be the first free encoder that could do more than 6 channels :thanks:

[jruggle]

Hello,
Aften 0.03 has been released.
http://jbr.homelinux.org/aften/

Aften now supports 8/16/24/32/float/double for wav input.
Also, I added a more complete channel remapping.

I don't have a lot of multi-channel wav files to test with, so just let me know if I broke anything.

Thanks,
Justin

[Kurtnoise]

Great :)...A build (http://kurtnoise.free.fr/misc/aften-0.03.zip) for testing.

[Rockaria]

Wow, very fast integrations!!!!:eek:

-Dynamic range compression (DRC):
...
-Surround channel processing->90 degree phase shift
-Surround channel processing->3 dB atenuation
AFAIK, there are three places to enable the DRC : DD encoding time, DD decoding time and decoded PCM DRC solutions(AC3filter..)
I am not sure how much these DD encoding/decoding time DRC(film, music, speech...) are related : actual range alteration in encoding time or just setting the desired DRC option tag info. I hope somebody put some clarification on this...

In addition to the discrete DD 5.1 encoding, the DPL (II) encoding also might be very useful to some multi-platform users.
The (old commercial) softEncode generated perfect 90 deg shifted surrounds when I tested. So if this ffmpeg lib(or anyhow) supports this routine, I believe it can even (invert) matrix mix the DPL II PCM for any destinations : DD2.0, WAV, STDOUT...

It will also complete the purpose of the surrounds-90deg-shifts and the DS mode meta tag for the play/encoding time DPL(II) downmix.
a) play time DPL(II) downmix : the stream contains original multi channel(DD5.1)
- the encoder performs the 90 deg shift(s) on S or SL/SR
- the player performs simple stereo(Lo/Ro), DPL(Lt/Rt), DPL II downmix for a DPL(II)/stereo only-receiver.
- the player simple stereo mixer performs simple stereo downmix(Lo/Ro) for a stereo receiver.
- the player DPL downmix performs invert on S : Lt = (L, 0.707(C, LFE), -0.707S), Rt = (R, 0.707(C, LFE), 0.707S)
- the player DPL II downmix performs invert on SurroundCoefs : Lt = (L, 0.707(C, LFE), -(0.866Ls, 0.5Rs), Rt = (R, 0.707(C, LFE), (0.866Rs, 0.5Ls))
b) encoding time DPL(II) downmix : the encoder also performs the required downmix to 2ch PCM

Well, I have been looking for a 90 deg phase shift(all-pass filter) plugin for avisynth with no success. Hope Aften is going to include it for a FULL Dolby support..:)

[tebasuna51]

AFAIK, there are three places to enable the DRC : DD encoding time, DD decoding time and decoded PCM DRC solutions(AC3filter..)
I am not sure how much these DD encoding/decoding time DRC(film, music, speech...) are related : actual range alteration in encoding time or just setting the desired DRC option tag info. I hope somebody put some clarification on this...
DRC at encoding time
For each block (256 audio samples, 5.33 ms. if 48 KHz) in ac3 stream there are:
(from ATSC Standard: Digital Audio Compression (AC-3), Revision A (http://www.dolby.com.cn/gb/assets/pdf/tech_library/a_52a.pdf))
5.4.3.3 dynrnge:-Dynamic range gain word exists, 1 bit
If this bit is a 1, the dynamic range gain word follows in the bit stream.

5.4.3.4 dynrng: Dynamic range gain word, 8 bits
This encoder-generated gain word is applied to scale the reproduced audio as described in Section 7.7.1.
The solution for free encoders is set always dynrnge = 0 (DRC = None). Commercial encoders can calculate the appropriate value for dynrng byte for each block, in function of selected DRC (film, music, ...)

DRC at decoding time
A decoder can offer to the user:
a) Ignore the DRC info in ac3 stream and apply, or not, a new DRC analyzing the signal (Ac3Filter).
b) Accept the DRC info in ac3 stream and:
b1) Apply the full dynamic range (Azid-none, NicAc3Source(), PowerDVD-Quiet)
b2) Apply the DRC encoder-calculated (ffdshow, Azid-normal, NicAc3Source(DRC), PowerDVD-Normal)
b3) Modify the DRC encoder-calculated (Azid-Light, Azid-Heavy, PowerDVD-Noisy)

If an ac3 don't have DRC info (DRC=none, free encoders), b1) = b2) and the ac3 is always reproduced at full dynamic range in players without specifics DRC algorithms.

[jruggle]

Aften 0.03 has been released.

I forgot to mention that I changed the VBR and auto-bandwidth settings as well. Default quality is now 220 instead of 200. Also, bandwidth is not reduced quite as much as it was before.

-Justin

[Rockaria]

@tebasuna, that seems to be the (almost) complete explanation on the existing DRC solutions, and thanks for the link.:goodpost:
The DD encoding time dynrnge/dynrng values do not seem to be the actual range alteration but the desired/calculated level appliable and adjustable in decoding time. In the '7.7 Dynamic Range Compression' section of the same document :
...While this satisfies the needs of much of the audience, it removes the ability of some in the audience to experience the original sound program in its intended form. The AC-3 audio coding technology solves this conflict by allowing dynamic range control values to be placed into the AC-3 bit stream.
The dynamic range control values, dynrng, indicate a gain change to be applied in the decoder in order to implement dynamic range compression. Each dynrng value can indicate a gain change of ±24 dB. The sequence of dynrng values are a compression control signal. An AC-3 encoder (or a bit stream processor) will generate the sequence of dynrng values. Each value is used by the AC-3 decoder to alter the gain of one or more audio blocks....One of my h/w receivers has the DRC option (0.0/1.0/0.5 : I guess none/full/light) manually adjustable. The other has no control, maybe FULL.

So this original DD DRC option seems not as flexible as that of the AC3Filter but still must be a necessary option for those who have the H/W receivers(no s/w ac3filter) and not so quite listening environment but wish not to miss the details at the cost of the reduction of the scale(range)...
Like DPL II, this FULLY considered DRC is regarded as a must option to some while none of the interest to others(like DD EX to me atm).;)

[tebasuna51]

Hello,
Aften 0.03 has been released.

Aften now supports 8/16/24/32/float/double for wav input.
Also, I added a more complete channel remapping.

I think this can improve WAVE_FORMAT_EXTENSIBLE, at wav.c line 101:
...
wf->bit_width = read2le(fp);
wf->filepos += 2;
if(wf->bit_width == 0) return -1;
chunksize -= 16;
// WAVE_FORMAT_EXTENSIBLE data
int chmask = 7;
if(wf->format == WAVE_FORMAT_EXTENSIBLE && chunksize > 0) {
// chmask isn't after bit_width, before there are CbSize and ValidBitsPerSample (4 bytes)
read4le(fp);
wf->filepos += 4;
// Now ChMask
chmask = read4le(fp);
wf->filepos += 4;
// And now we can read the SubFormat valid if WAVE_FORMAT_PCM or WAVE_FORMAT_IEEEFLOAT
wf->format = read2le(fp);
wf->filepos += 2;
chunksize -= 10;
}
// determine channel mode
if(wf->channels == 1) {
wf->ch_mode = CH_MODE_1_0;
} else if(wf->channels == 2) {
wf->ch_mode = CH_MODE_2_0;
} else if(wf->channels == 3) {
if(chmask & 0x7) wf->ch_mode = CH_MODE_3_0;
else wf->ch_mode = CH_MODE_2_1;
} else if(wf->channels == 4) {
if(chmask & 0x7) wf->ch_mode = CH_MODE_3_1;
else wf->ch_mode = CH_MODE_2_2;
} else if(wf->channels == 5) {
wf->ch_mode = CH_MODE_3_2;
} else if(wf->channels == 6) {
wf->ch_mode = CH_MODE_3_2_1;
} else {
wf->ch_mode = CH_MODE_OTHER;
}

[jruggle]

Thank you! It seems I read through the specs a little too quickly. Your changes have been applied to the current development version.

-Justin

[NorthPole]

Aften 0.03 has been released.
Aften now supports 8/16/24/32/float/double for wav input.
Also, I added a more complete channel remapping.


Thanks Justin for your work! Works good so far.

[Mug Funky]

i'm trying out this version:
http://forum.doom9.org/showthread.php?p=853847#post853847

CBR appears broken? i type in -b 224 and it says "error initialising encoder". that might be my fault though.

also, it seems that when a very high -q is selected (400), it'll refuse give this error a lot:

Error encoding frame xxxx
bitrate: 640 kbps too small

it seems this would be simple to fix?

i'm watching this encoder :) thanks for developing it.

[edit]

oh, i forgot: P4 with hyperthreading

[jruggle]

i'm trying out this version:
http://forum.doom9.org/showthread.php?p=853847#post853847

CBR appears broken? i type in -b 224 and it says "error initialising encoder". that might be my fault though.
The bitrate needs to be specified in bps, not kbps. So you need to use "-b 224000".


also, it seems that when a very high -q is selected (400), it'll refuse give this error a lot:

Error encoding frame xxxx
bitrate: 640 kbps too small

it seems this would be simple to fix?
I fixed this earlier today, so the current development version should work. Now it will continue lowering the quality for each frame to values below the selected quality until the data fits in a 640kbps frame. Before it was returning an error instead of going below the requested quality setting.

-Justin

[Mug Funky]

haha! sweet. i read the bitrate thing earlier in the thread, but it didn't occur to me :(

thanks for the quick reply.

[guada2]

Great job Kurtnoise13 :)

Just 2 questions:
* nero show time 2 information: 2.1 (Why?)
* Media player classic: 6.1 (Right)

Vlc doesn't play your file ac3, your opinion ?

Bye.

[SeeMoreDigital]

Great job Kurtnoise13 :)

Vlc doesn't play your file ac3, your opinion ?Personally speaking I've never been able to set-up VLC player to correctly output AC3 sources to my external DSS amplifier :eek:

[guada2]

Hey SMD,

It is just a report, only that....
I suppose that you understand...

Thanks.

[Kurtnoise]

Just 2 questions:
* nero show time 2 information: 2.1 (Why?)
In Options Settings --> Audio --> Use 6 speakers.

Vlc doesn't play your file ac3, your opinion ?
It does...During the playback, you are able to change the device (switch stereo to 5.1).

[Chainmax]

This one keeps looking better and better, Scenarist's and Vegas's AC3 encoders had better watch their backs :).

jruggle: do you think sometime in the future Dibrom and Aoyumi could help implement some of LAME's and aoTuV's features if such a thing is feasible at all?

[tebasuna51]

@jruggle
Tested aften v0.03 and work for 8/16/24/32 bits int and float, only float WAVE_FORMAT_EXTENSIBLE wait for a new version (corrected in current sources).

Only one more thing: the test to select CH_MODE_3_0 or CH_MODE_3_1 (center channel present) must be (chmask & 0x4) instead (chmask & 0x7).

Thanks.

[jruggle]

This one keeps looking better and better, Scenarist's and Vegas's AC3 encoders had better watch their backs :).
I wasn't really aware of either of these. I googled them to find they are commercial software. I probably have quite far to go before catching up. And now with E-AC3/DDP on the horizon I'll have to work double-fast. ;) I really need to do more extensive studies of commercially-generated AC3 files so I can better optimize Aften. My first attempt at channel coupling about 6 months ago was not successful, but I hope the 2nd attempt will work.

jruggle: do you think sometime in the future Dibrom and Aoyumi could help implement some of LAME's and aoTuV's features if such a thing is feasible at all?
Well...as far as aoTuV...I don't think it applies. I might be wrong though. AC3 has a very specific psycho-acoustic model which uses an algorithm which is pretty tightly tied to the format. There may be some overlap in the concepts though. Right now I am just using the basic settings recommended by the spec.

The one feature which LAME has that I hope to understand better once I get into it is ABR encoding. I know the concepts, but not the nitty-gritty of it. I'll just have to do some research. I want to do several other things before I dive into that though.

Only one more thing: the test to select CH_MODE_3_0 or CH_MODE_3_1 (center channel present) must be (chmask & 0x4) instead (chmask & 0x7).
Doing (chmask & 0x7) checks for the presence of left, right, and center all at once...either way works though. I'm going to be changing this to a more robust solution which checks to make sure the channel configuration is even supported in AC3 instead of assuming which channels are there.

I do have a related question. I'm fairly new to surround encoding...so I'm not 100% sure about which mask values correspond to surround, left-surround, and right-surround. I know someone here will have a definite answer. :) Here is the list of channels for reference.


#define SPEAKER_FRONT_LEFT 0x1
#define SPEAKER_FRONT_RIGHT 0x2
#define SPEAKER_FRONT_CENTER 0x4
#define SPEAKER_LOW_FREQUENCY 0x8
#define SPEAKER_BACK_LEFT 0x10
#define SPEAKER_BACK_RIGHT 0x20
#define SPEAKER_FRONT_LEFT_OF_CENTER 0x40
#define SPEAKER_FRONT_RIGHT_OF_CENTER 0x80
#define SPEAKER_BACK_CENTER 0x100
#define SPEAKER_SIDE_LEFT 0x200
#define SPEAKER_SIDE_RIGHT 0x400
#define SPEAKER_TOP_CENTER 0x800
#define SPEAKER_TOP_FRONT_LEFT 0x1000
#define SPEAKER_TOP_FRONT_CENTER 0x2000
#define SPEAKER_TOP_FRONT_RIGHT 0x4000
#define SPEAKER_TOP_BACK_LEFT 0x8000
#define SPEAKER_TOP_BACK_CENTER 0x10000
#define SPEAKER_TOP_BACK_RIGHT 0x20000
#define SPEAKER_RESERVED 0x80000000


Thanks,
-Justin

[jruggle]

I'm adding stuff to Aften so quickly I feel like I need a development blog so I can stop posting here so often. ;) On the road to implementing DRC, I have made a little utility which calculates RMS. It also does something very similar to replaygain (but not exactly identical) to make a better dialog normalization guess than average RMS. It needs much more testing, but seems to work well so far.

The file is wavrms.c, and it is in the aften/util source directory of the lastest development version.

[tebasuna51]

I do have a related question. I'm fairly new to surround encoding...so I'm not 100% sure about which mask values correspond to surround, left-surround, and right-surround. I know someone here will have a definite answer. :) Here is the list of channels for reference.
100% sure about:
#define SPEAKER_BACK_LEFT 0x10 = Left-surround = SL = BL
#define SPEAKER_BACK_RIGHT 0x20 = Right-surround = SR = BR

I never see a sample WAVE_FORMAT_EXTENSIBLE with Surround channel, maybe:
#define SPEAKER_BACK_CENTER 0x100 = Surround = S = BC

Then:
CH_MODE_3_0 (L,R,C) -> chmask = 0x0007
CH_MODE_2_1 (L,R,S) -> chmask = 0x0103

CH_MODE_3_1 (L,R,C,S) -> chmask = 0x0107
CH_MODE_2_2 (L,R,SL,SR) -> chmask = 0x0033

(chmask & 0x7) is always True with the four chmask, maybe you need ((chmask & 0x7) == 7) or (chmask & 0x4) to select the appropriate acmod.

[jruggle]

100% sure about:
#define SPEAKER_BACK_LEFT 0x10 = Left-surround = SL = BL
#define SPEAKER_BACK_RIGHT 0x20 = Right-surround = SR = BR

I never see a sample WAVE_FORMAT_EXTENSIBLE with Surround channel, maybe:
#define SPEAKER_BACK_CENTER 0x100 = Surround = S = BC

Thanks tebasuna51. I have updated Aften to do a more thorough check of chmask to make sure the channel layout is AC3-compatible. I also separated the AC3-specific code from the WAV parser.

-Justin

[Rockaria]

which mask values correspond to surround, left-surround, and right-surround.
wavinfo : http://www.soundslogical.com/support/mpacks/documentation/english/documentparts/wavinfo.html
chnmsk2spkrlist : http://www.soundslogical.com/support/mpacks/documentation/english/documentparts/chnmsk2spkrlist.html
...
"5.1 Surround Sound Format":
Channel order:Front Left, Front Right, Front Center, Low Frequency, Side Left, Side Right
ChannelMask (binary):'11000001111'
(hexadecimal):'60F'
(decimal):1551
...

Other wiki external links : http://en.wikipedia.org/wiki/Wav

[tebasuna51]

"5.1 Surround Sound Format":
Channel order:Front Left, Front Right, Front Center, Low Frequency, Side Left, Side Right
ChannelMask:'60F'
...
Maybe there are differents opinions.
The only decoder I know with output WAVE_FORMAT_EXTENSIBLE is faad and use ChannelMask 0x3F with this info:
---------------------
| Config: 5.1 Ch | WARNING: channels are reordered according to
--------------------- MS defaults defined in WAVE_FORMAT_EXTENSIBLE
| Ch | Position |
---------------------
| 00 | Center front |
| 01 | Left front |
| 02 | Right front |
| 03 | Left back |
| 04 | Right back |
| 05 | LFE |
---------------------
Maybe to avoid problems not related with ac3 encoding we may use this more simple:
// Determine acmod and lfe from WAVE_FORMAT_EXTENSIBLE channel mask
static void wav_mask_to_acmod(int ch, int chmask, int *acmod, int *lfe)
{
*lfe = !!(chmask & 0x08);
if(*lfe) {
ch--;
}
*acmod = 7;
if(ch == 1) {
*acmod = 1;
} else if(ch == 2) {
*acmod = 2;
} else if(ch == 3) {
*acmod = 4;
if(chmask & 0x4) *acmod = 3;
} else if(ch == 4) {
*acmod = 6;
if(chmask & 0x4) *acmod = 5;
}
}
Now default is acmod = 7 (open for future ch > 6), and the ambiguous ch 3 or 4 are selected only with the test over the center channel.

[Ebobtron]

---------------------
| Config: 5.1 Ch | WARNING: channels are reordered according to
--------------------- MS defaults defined in WAVE_FORMAT_EXTENSIBLE
| Ch | Position |
---------------------
| 00 | Center front |
| 01 | Left front |
| 02 | Right front |
| 03 | Left back |
| 04 | Right back |
| 05 | LFE |
---------------------

I found this recently, MS still offers this link in the PSDK concerning WAVE_FORMAT_EXTENSIBLE
http://www.microsoft.com/whdc/device/audio/multichaud.mspx
To quote the link from Microsoft listed above.
Default Channel Ordering
The way to deterministically link channel numbers to speaker locations, thus providing consistency among multiple channel audio files, is to define the order in which the channels are laid out in the audio file. Several external standards define parts of the following master channel layout:

1. Front Left - FL
2. Front Right - FR
3. Front Center - FC
4. Low Frequency - LF
5. Back Left - BL
6. Back Right - BR
7. Front Left of Center - FLC
8. Front Right of Center - FRC
9. Back Center - BC
10. Side Left - SL
11. Side Right - SR
12. Top Center - TC
13. Top Front Left - TFL
14. Top Front Center - TFC
15. Top Front Right - TFR
16. Top Back Left - TBL
17. Top Back Center - TBC
18. Top Back Right - TBR

So far all of the research that I have done seems to support the above list for all wave formats.

[tebasuna51]

So far all of the research that I have done seems to support the above list for all wave formats.
Yes, of course, the faad wav output have the correct order:
1. Front Left - FL
2. Front Right - FR
3. Front Center - FC
4. Low Frequency - LF
5. Back Left - BL
6. Back Right - BR

The discussion is:
a) soundslogical proposal:
5.1 Surround Sound Format:
Channel order:FL, FR, FC, LF, Side Left, Side Right
ChannelMask:'60F'
b) faad proposal:
5.1 Ch:
Channel order:FL, FR, FC, LF, Back Left, Back Right
ChannelMask:'3F'

[guada2]

@Kurtnoise,
Nero OK, But for VLC ?????

I use the latest VLC (0.85), and i didn't found nothing about in your explanation in this version.
It does...During the playback, you are able to change the device (switch stereo to 5.1).

It is not important, but i'm curious.
Could you precise more please.
:thanks:

[Kurtnoise]

http://img100.imageshack.us/img100/5476/vlcaudiodevicexc2.png

[SeeMoreDigital]

http://img100.imageshack.us/img100/5476/vlcaudiodevicexc2.pngSadly for me though, VLC's "A/52 over S/PDIF" option outputs corrupted bit-streams that my DSS amp can't decode :(

But don't panic.... because this happens with all my AC3 sources, regardless of the encoder used to generate them...


Cheers

[Rockaria]

VLC's "A/52 over S/PDIF" option outputs corrupted bit-streams that my DSS amp can't decode
That's very true for me too who also completly forgot playing(decoding) through the the analog 5.1ch speaker.;)
But iirc when I feed the 48khz-16~24bit sources(anyhow), it satisfies the codec(spdif-out) to sync with the external decoder.


Several external standards have been compiled by Microsoft into the following default channel ordering list:
And now we see different examples(suggestions, opinions, proposals) on the rear surround 2 channels from 5.x ch formats.
. ms, faad : BL, BR which are also used in quad
. soundlogic : seems starting to reflect the actual/effective speaker locations

Upto 5.1, there would be no problem in extracting the two rears whether they have more resonable names or not, by the physical channels imbeded orders : FL,FR,C,LFE, (BL, BR) | (SL, SR)

But in soundlogic's examples from 6.1ch, the listed channel orders start to differ from the actual imbeded channel orders. Maybe we need some optional remappings to extract correct channels practically:
6.1ch : ,,,, Side Left, Side Right, Back Center -> ,,,, BC, SL, SR
7.1ch : ,,,, Side Left, Side Right, Back Left, Back Right -> ,,,, BL, BR, SL, SR

In my opinion, because the WAVE_FORMAT_EXTENSIBLE is defined so clear about the orders of the extra (surround) channels, it can replace the WAVE_FORMAT_PCM to be used for the decoded PCM channel orders, but may require the remappings like above practically for the differently imbeded WAVE_FORMAT_EXTENSIBLE over 5.1ch by the ChannelMask and possibly with some other info.

[vlada]

I have one simple question: does the encoder support pipes? I want to use Aften in foobar2000 where it would be very useful. From what I tried it doesen't work. The problem is, that sometimes you can't create an intermediate WAV file, because it would exceed a 4 GB WAV limit.

Also it would be useful to implement SSRC sample rate conversion and force a 48 kHz resampling if needed. foobar2000 can force output to 16 bit but not 48 kHz AFAIK.

Edit: Resampling can be done using foobar's DSP processing.

[jruggle]

b) faad proposal:
5.1 Ch:
Channel order:FL, FR, FC, LF, Back Left, Back Right
ChannelMask:'3F'
a52dec (liba52) also uses 0x3F as the channel mask for 6-channel wav output.

Maybe to avoid problems not related with ac3 encoding we may use this more simple:

// Determine acmod and lfe from WAVE_FORMAT_EXTENSIBLE channel mask
static void wav_mask_to_acmod(int ch, int chmask, int *acmod, int *lfe)
{
*lfe = !!(chmask & 0x08);
if(*lfe) {
ch--;
}
*acmod = 7;
if(ch == 1) {
*acmod = 1;
} else if(ch == 2) {
*acmod = 2;
} else if(ch == 3) {
*acmod = 4;
if(chmask & 0x4) *acmod = 3;
} else if(ch == 4) {
*acmod = 6;
if(chmask & 0x4) *acmod = 5;
}
}


Normally I tend to favor solutions which don't cater to incorrect ways of doing things, as it only perptuates the problem. In this case, I think it is better to check all the mask values instead of assuming that the correct channel-to-speaker mapping exists. Are there other sources besides soundlogic which produce 5.1 wavs with a channel mask other than 0x3F? If not I'm leaning toward a more strict solution. Or maybe explicitly checking for either of the 2 ways, back or side. I'd rather not leave it open for any configuration with X number of channels. Comments?

-Justin

[jruggle]

I have one simple question: does the encoder support pipes? I want to use Aften in foobar2000 where it would be very useful. From what I tried it doesen't work. The problem is, that sometimes you can't create an intermediate WAV file, because it would exceed a 4 GB WAV limit.
Aften should support pipes... What problems are you having? It definitely works in Linux, and the Windows piping support was based on someone else's (presumably working) patch.

Also it would be useful to implement SSRC sample rate conversion and force a 48 kHz resampling if needed. foobar2000 can force output to 16 bit but not 48 kHz AFAIK.

Edit: Resampling can be done using foobar's DSP processing.
Inline resampling is on my TODO list. Also, optionally downmixing or upmixing the number of channels is on the TODO list. :) The list just keeps growing!

-Justin

[Kurtnoise]

@vlada : no problem with pipeline here with fb2k...

@all : my Aften builds for win32 OS are located here (http://kurtnoise.free.fr/index.php?dir=Aften/) now. The last current version corresponds to the 0.03-dev. :)

[tebasuna51]

I have one simple question: does the encoder support pipes?
I want to use Aften in foobar2000 where it would be very useful. From what I tried it doesen't work. The problem is, that sometimes you can't create an intermediate WAV file, because it would exceed a 4 GB WAV limit.
Yes, work with Bepipe/BeHappy and foobar, also with wav > 4GB

[tebasuna51]

Normally I tend to favor solutions which don't cater to incorrect ways of doing things, as it only perptuates the problem. In this case, I think it is better to check all the mask values instead of assuming that the correct channel-to-speaker mapping exists. Are there other sources besides soundlogic which produce 5.1 wavs with a channel mask other than 0x3F? If not I'm leaning toward a more strict solution. Or maybe explicitly checking for either of the 2 ways, back or side. I'd rather not leave it open for any configuration with X number of channels. Comments?
Ok, not problem for me.

Edit:
@Kurtnoise
Thanks for your last aften.exe, now work WAVE_FORMAT_EXTENSIBLE float wav.

[jruggle]

Ok, not problem for me.
Done. Also, I have created a place for a more detailed Changelog of sorts.
http://aftenblog.blogspot.com/

-Justin

[vlada]

@vlada : no problem with pipeline here with fb2k...


It doesen't work for me. I just tried it on another machine with your latest build. I get this error message:
Error writing to file (Encoder has terminated prematurely with code 1;
please re-check parameters) : file://C:\sample.ac3

It works with parameters -b 256000 %s %d, but if I remove the %s switch (which creates an intermediate WAV file) I get the error mentioned above.

What parameters have you used in foobar2000?

[tebasuna51]

With: -b 448000 - %d
Replace '%s' with '-'

[vlada]

@tebasuna51> Thanks, now it works fine.

[SeeMoreDigital]

Hi Kurtnoise13,

Will it be your intension to add this new AC3 encoder to BeLight at some point?


Cheers

[Kurtnoise]

Yes, it's planned but for the moment it doesn't work properly. Maybe an issue with bsn.dll...

[danpos]

@kurtnoise

I did use AftenGUI 1.1 with Aften 0.3-dev. I did use the drag'n'drop feature and it worked great. I did encode a batchlist with 5 waves files to AC3, using the same settings than I use with SoftEncode and the resulting AC3 files working great (and the time for total batch encode was very quick compared with SoftEncode).

Thank you for the W32 build/GUI and Justin Ruggles for this great encoder.

JFYI. :)

Regards,

[Kurtnoise]

@Danpos : great...:)

@Justin : about library integration. Why not submit a patch for libsndfile ?

[raquete]

After the test I think Aften is the best free ac3 encoder.

I want compare the options with the old reference encoder Sonic Foundry SoftEncode (in speed Aften is clearly the winner, Softencode need hours to encode a 6 chan 130 min long)

this sounds exciting...

I did encode a batchlist with 5 waves files to AC3, using the same settings than I use with SoftEncode and the resulting AC3 files working great (and the time for total batch encode was very quick compared with SoftEncode).

good posts! :cool:

i confirm.
Aften is faster,the sound have more "punch" and is more clever than from softencode(that i removed from my system).
another detail is that softencode use "low pass filter"(20 ~ 120Hz) to encode LFE and Aften encode my .wavs 6 channels without change my parameters.

AftenGui is now my "emperor" AC-3 encoder.

Kurtnoise13 & jruggle (tebasuna51 and all that help)
congratulations!
;)

[Rockaria]

I kinda feel the seniority or maturity on everything in this project. C not c++ nor net and ,, java (itself is a perfect language in the server level computing), by gathering lots of interests and satisfactions already with the v0.03, and having the clear objectives and open approaches, not necessarily driven by the NEW technology.

Although I cannot make you guys happier with the cheerleading and nominating, I admit I have almost nothing to add to the development but just wait and evaluate the outputs( including the clearly organized sources). I just wanted the discussions a tad bit more based(with formal references) and considered in easy words.
Myself being a music lover than a movie manicac, I am more focused on the player/mixer level DD/DPL II link to the receivers than encoding clips(I might still prefer AAC though).
But doing things correctly in a fully considered open approaches is certainly the wonderful thing to be appreciated. It looks like genuine.

[raquete]

i'm using AftenGui to encode AC-3 5.1 in musics extracted from cds following the ursamtl's a.audition guide.
i have doubts about possibles values(metadata).

for audio(audio-dvds) i have to adjust Aften to -31, -27 or -15 in dialog normalization?
i want to know about "stereo rematrixing","Dolby Prologic Mode","block switching" and "bandwidth" adjusts too.

can anyone help me please?

thanks.

[jruggle]

i want to know about "stereo rematrixing","Dolby Prologic Mode","block switching" and "bandwidth" adjusts too.
Stereo rematrixing is the AC-3 version of mid/side or channel decorrelation. It is done in the frequency domain and only in a selected frequency range. This generally increases quality (CBR) or decreases bitrate (VBR). It is also important for use with Dolby Prologic. The spec explains how, but I have not given sufficient mind time to really figuring out the in-phase/out-of-phase stuff.

Dolby Prologic (Surround) Mode is just a flag that indicates the input audio has been Dolby Prologic encoded. Aften doesn't do anything to the audio.

Block switching is the use of both the standard 512-point MDCT transform and the short-block 256-point MDCT. The short block transform is better for transient signals. The spec details exactly how an encoder should make the block switching decision. There are other methods out there which claim to do a better job, but for now Aften just does what the spec says. Using block switching is slower since it involves a high-pass filter before analysis (the filtered audio is not encoded, just used for the block switching decision).

The bandwidth setting determines the cutoff frequency. This ranges from 0 to 60. Note that even at the highest setting, only 253 of the 256 coefficients are encoded, so the full bandwidth is never used. Aften's variable bandwidth mode selects a bandwidth for each frame based on the quality (snr offset) for that frame. The formula for figuring cutoff frequency from the bandwidth code is:
cutoff = (samplerate/2) * (((bw * 3) + 73) / 256)
to reverse it:
bw = (((cutoff / (samplerate/2)) * 256) - 73) / 3

If you want to cutoff around 16kHz, you can set a constant bandwidth of 33 for 48kHz audio or 38 for 44kHz audio.

Hope this helps.
-Justin

P.S. Thanks everyone for all the compliments and encouragement! :)

[guada2]

* Sorry and thank you very much Kurtnoise13.

* Very :goodpost:

Bye.
Mario.

[raquete]

Hope this helps.
-Justin

:)
:goodpost: :helpful:
help too much. :D

thank you.

[Rockaria]

My research could have been more specific on the ProLogic issue...

DP569 Dolby Digital Encoder http://dolby.com/assets/pdf/tech_library/133_m.ch.0002.DP569Guide_Chart.QuickStart.pdf
DP563 Dolby Surround and Pro Logic II Encoder http://dolby.com/assets/pdf/tech_library/148_563_2.Manual.pdf
DP564 Multichannel Audio Decoder http://dolby.com/assets/pdf/tech_library/134_DP564QuickStartGuide.pdf

ATSC Standard: Digital Audio Compression (AC-3), Revision A http://www.dolby.com.cn/gb/assets/pdf/tech_library/a_52a.pdf

Beside having bsi->5.4.2.6 dsurmod for the decoder(DP564 ) auto mode to determine the proper DPL(II) decoding for the 2.0 streams encoded from DPL II encoder(DP563), the annex c->2.3.1.2 dmixmod for the auto downmixing is designed to help the DP564 to determine the proper mode if presents.
As is explained in the DP563 manual->2.4 Metadata, the default Lt/Rt mode is preferred if the surround is ready to (invert) downmix(i.e. 90deg rear phase shifted with DP569 option).

However, the decoding time Lt/Rt downmix mode will have very rare opportunities to be used as is than the original DPL II, stereo downmix or as the input for dolby virtual speaker/dolby headphone dsp :
- if connected from a player, the receiver(DPL II decoder) will mostly also have the DD decoding for 6ch speaker set
- if 2ch play is the constraint, the virtual speaker or dolby headphone DSPs would be better for more spatial effect.

<my understanding of the Dolby devices' scope>
DP570 Multichannel Audio Tool | EX-EU4 Dolby EX Surround Encoder | DP563 Dolby Surround and Pro Logic II Encoder,,, : preprocessing or mixing
DP569 Dolby Digital Encoder | DP571 Dolby E Encoder | DD Live | Dolby Media Producer ...: encoding
DP562 Dolby Digital Decoder | DP572 Dolby E Decoders | DP564 Multichannel Audio Decoder ...| EX-DU4 Dolby EX Surround Decoder : decoding & post procesing
... Aften is located somewhere intended to cover some area(mostly DP569) of the functionalities of current devices.. (hopefully) to be progressively evolving...

http://dolby.com/assets/pdf/tech_library/DPlus_TrueHD_whitepaper.pdf
The conventional rematrixing(a different approcah than the decoder-downmixing) on lossy codecs to reconstruct the 5.1 or 7.1 channels with the 'downmix + extention' mechanism is known to have the 'coder unmasking' side effect(page 4), but I guess AC3's (section 7.5) rematrixing will be useful to effectively reduce the bit rate especially when VBR is used, in addition to the channel coupling maybe.
[edit] rematrixing : it seems related but differs a lot from the AC3 spec rev. A->7.5 rematrixing. I wonder if this type of rematrixing has ever been used with Dolby.
Dolby Digital was not bound to any prior channel extension methodology, and could therefore benefit from the subsequent developments of other multichannel codecs..Dolby ac3 is using the decoder-downmixing for the 2ch compatibility and the above extention methodology is totally different from the ac3's rematrixing.

[jruggle]

Beside having bsi->5.4.2.6 dsurmod for the decoder(DP564 ) auto mode to determine the proper DPL(II) decoding for the 2.0 streams encoded from DPL II encoder(DP563), the annex c->2.3.1.2 dmixmod for the auto downmixing is designed to help the DP564 to determine the proper mode if presents.
As is explained in the DP563 manual->2.4 Metadata, the default Lt/Rt mode is preferred if the surround is ready to (invert) downmix(i.e. 90deg rear phase shifted with DP569 option).

However, the decoding time Lt/Rt downmix mode will have very rare opportunities to be used as is than the original DPL II, stereo downmix or as the input for dolby virtual speaker/dolby headphone dsp :
- if connected from a player, the receiver(DPL II decoder) will mostly also have the DD decoding for 6ch speaker set
- if 2ch play is the constraint, the virtual speaker or dolby headphone DSPs would be better for more spatial effect.

Since it will be pretty simple to do, I'll go ahead and add the alternate bitstream syntax. Since Aften does not use timecodes, it will be the same as it is now unless the user specifies a setting for one of the options in the alternate syntax.

-Justin

[raquete]

trying to help the thread after got great gratifications:

Pro Logic II ... Left .. Right Center Rear Left Rear Right
Left Total .... 1.000 0.000 0.707 .. j0.8165 .. j0.5774
Right Total ... 0.000 1.000 0.707 . k0.5774 .. k0.8165

j = + 90º phase-shift , k = - 90º phase-shift

http://en.wikipedia.org/wiki/Matrix_decoder#Dolby_Pro_Logic_II__Matrix_.282:5.29

from ATSC: A/52B (Digital Audio Compression (AC-3, E-AC3) Standard, Rev. B)
Digital Audio Compression (AC-3, E-AC3) Standard, Rev. B
"Revision B added a new annex, “Enhanced AC-3 Bit Stream Syntax” which specifies an additional syntax that offers additional coding tools and features."
http://www.atsc.org/standards/a52.html
http://www.atsc.org/standards/a_52b.pdf

and some more "standards"
http://www.atsc.org/standards.html



i'm still searching answer for this question(for more than i read i can't find:
for audio(audio-dvds) i have to adjust Aften to -31, -27 or -15 in dialog normalization?

thanks.

[Kurtnoise]

i'm still searching answer for this question(for more than i read i can't find:
for audio(audio-dvds) i have to adjust Aften to -31, -27 or -15 in dialog normalization?

thanks.
From the sticky (http://forum.doom9.org/showthread.php?t=56020)...

Referencing Volume to a Known Level - Dialogue Normalization

To meet the Dolby Digital requirement that different programs should have approximately the same listening level (thus the consumer does not have to adjust volume level between programs), Dolby Digital incorporates a parameter called dialogue Normalization. This metadata parameter tells the decoder how far away from the reference level the average sound pressure level of the material's dialogue is.

The movie industry masters their soundtracks in a specific way. The maximum rated sound level (where all amplifiers are putting out their rated power) is 0 dB. Sounds below that level are rated in terms of how many decibels (dB) they are down from that maximum level. As such, these values are negative. The movie industry typically masters the "normal" listening level of dialogue (where people are speaking in a normal voice) at -31 dBFS. In other words, a speaking voice is at an average of -31 dB when referenced to the 0 dB maximum sound level, hence the term decibels of full scale (dBFS).

Since movie content is the largest class of programs to go on DVD, Dolby chose -31 dBFS as the reference level for audio on DVD, where 0 dB represents the maximum encodable digital sound level (full scale).

The dialogue normalization parameter needs to be set to the LAeq level of your program material's dialogue. LAeq stands for the long-term A-weighted sound pressure level. Loosely, this is the average volume level of your source material's dialogue. Us lowly consumers really don't have a tool that can measure this parameter, but we can get close. Sonic Foundry's Sound Forge has a "Normalization" feature that can measure the RMS level of a .wav file (or the portion thereof containing dialogue). CoolEdit may also have a feature like this. To use it in Sound Forge, open your .wav file containing the movie audio. Select a section containing dialogue (no sound effects or music). Go to "Process"/"Normalize". Select the "Average RMS Power (Loudness)" radio button. Then click the "Scan Levels" button. The displayed "RMS" level is very close (within 1-2 dB) to the LAeq level.

That RMS level is the number that the dialogue normalization parameter should be set to. In other words, if the RMS level in Sound Forge shows as -17.6 dB, set the dialogue normalization parameter in your Dolby Digital encoder to -18 dBFS.

The decoder will perform an attenuation of (31 + dialnorm) dB to the program material when played back. So, in this case, the decoder will attenuate by (31 + -18) = 13 dB. This will bring the average sound level of the material to (-17.6 - 13) = -30.6 dBFS. The program is now played back at approximately -31 dBFS, the reference level.

-31 dBFS is a lower average volume level than what is typical from other sources. It will be noticeable that you will have to turn the volume up on your system when playing a DVD versus playing broadcast, tape, or other non-Dolby Digital program material.

[Rockaria]

trying to help the thread after got great gratifications:

Pro Logic II ... Left .. Right Center Rear Left Rear Right
Left Total .... 1.000 0.000 0.707 .. j0.8165 .. j0.5774
Right Total ... 0.000 1.000 0.707 . k0.5774 .. k0.8165

j = + 90º phase-shift , k = - 90º phase-shift
AFAIK, this coefficient(matrix) issue is handled in other thread where yourself also participated in. I might be wrong here...
Many have confirmed the 1:3dB sound pressure ratio model(0.866, 0.5) seperates the rears better than the quoted 1:2 ratio model.( I also TESTED and confirmed it)
The downmix itself is currently beyond the scope of several AC3 encoders(DP569, sodtEncode...) while they only provide the option for the rears to be 90deg phase shifted to be ready for the decoder-downmix(where one rear coef channel will be inverted) for the 2ch speaker set compatibility.

Also this functionality is mentioned in the manuals of current Dolby's related devices, which is why I wanted to mention it in this thread.
Anyway, It would be great to know what functionalities from the revised specs and standards you want to integrate in this s/w....

BTW, I thought just reflecting the memory would be enough than quoting the whole contents in this case... I might be wrong here also.;)

[raquete]

@ Kurtnoise13
From the sticky...right,i knew that stick.:)
there,SomeJoe was treating "Films Light"(http://pages.sbcglobal.net/wilsondr/ddexacid4.gif)soundtracks,i was unclear when asking(and maybe again here,sorry :eek: )
i mean "audio dvds" as dvs with musics only (audio-dvd with single menu with pictures),and reading 18_metadata.guide.pdf(2005 Dolby laboratories) from Dolby.inc
in
6 Metadata Combinations(bottom of the .pdf)
note: these parameter settings are provided as examples to demonstrate that different settings can be saved,named,and brought up as needed for quick use in different situations.
the settings are not recommendations,but could be used as a starting point from which to create your own metadata values.
examples of possibles metadata settings
...
Dialogue Level:
Action Film -27 dB, Drama -27 dB, Local News -20 dB, Music -15 dB, Live Sporting Events -18 dB.

i still have to follow the SomeJoe's guide for audio-dvds(music only) ? :confused:


@ Rockaria

from back to front:
BTW, I thought just reflecting the memory would be enough than quoting the whole contents in this case... I might be wrong here also.
...is handled in other thread where yourself also participated in. I might be wrong here...
of course,i remember.
i found this informations from wikipedia "table" yesterday,was tasting as "fresh news" for me.

.( I also TESTED and confirmed it)ok,it's the end of my doubts! :cool:


:thanks: you all.
:)

[Rockaria]

ok,it's the end of my doubts! :cool: Cool! I am relieved now you are attended. :thanks:
And one more :thanks: for the links probably mostly useful for my future resarches(bases, references)...
@Justin,
I think the DPL(II) downmix implementation won't have the higher priority in the Aften development. It requires the 90deg phase shift on the rears(might be a hard work to correctly implement) to be ready for the simple downmix in the decoders(without the expensive all-pass filter equipped)
And I guess the annex->dmixmod is ideal to be set automatically(internally) by the 'rear phase shift' option selection when the source actually has the rear channels(4.0~).

Thanks.

[Kurtnoise]

A new dev build (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften-0.03-dev.zip) for testing...Check Justin's blog to have some extra informations.



@Justin: about wavrms. To avoid some errors during compilation I added

#include "../wav.h"
#include "../wav.c"


in wavrms.c. Not tested on my linux box though. Only on windows.

[chickenmonger]

Disclaimer: I'm not a programmer, just a user. I apologize if this seems demanding.

If I recall correctly, both Aften and Besweet's ac3enc.dll are taken from the same FFMPEG sources? If that's the case, does the current version of Aften suffer from the same three ( 1 (http://forum.doom9.org/showthread.php?s=&threadid=43466) 2 (http://forum.doom9.org/showthread.php?s=&threadid=34061) 3 (http://forum.doom9.org/showthread.php?s=&threadid=52263) ) bugs currently unfixed?

Can these be investigated?

Also, could Aften be folded into BeSweet, so it could be used as a drop-in replacement? Thanks.

[tebasuna51]

If I recall correctly, both Aften and Besweet's ac3enc.dll are taken from the same FFMPEG sources? If that's the case, does the current version of Aften suffer from the same three ( 1 (http://forum.doom9.org/showthread.php?s=&threadid=43466) 2 (http://forum.doom9.org/showthread.php?s=&threadid=34061) 3 (http://forum.doom9.org/showthread.php?s=&threadid=52263) ) bugs currently unfixed?
At least 3 Low volume ac3 (http://forum.doom9.org/showthread.php?s=&threadid=52263) bug is solved since ffmpeg CVS 2006-04-28. Of course also in Aften.

Others know bugs are solved also in ffmpeg (at March 2004, maybe not in ac3enc.dll for BeSweet). If still remain any problem with Pioneer DVD hardware players must be detected with new test, with my hardware/software players works ok.

[jruggle]

At least 3 Low volume ac3 (http://forum.doom9.org/showthread.php?s=&threadid=52263) bug is solved since ffmpeg CVS 2006-04-28. Of course also in Aften.
:) Yep...I think that was the hardest sell I've ever had to make for a patch.

Others know bugs are solved also in ffmpeg (at March 2004, maybe not in ac3enc.dll for BeSweet). If still remain any problem with Pioneer DVD hardware players must be detected with new test, with my hardware/software players works ok.
I don't know anything about the Pioneer problem...I'm not sure it was ever addressed on FFmpeg-devel. There was a bug fix quite a while ago that dealt with an error in how the header was written. That might have been to fix this bug, but I'm not sure.

I can't really tell what bug #2 was...the thread goes all over the place. It looks like it might have been a BeSweet or Azid issue. Part of the problem seems to be CRC errors. I do know Aften's CRC code works just fine, as I just reorganized it a bit and added a double-check in the code for safe measure.

-Justin

[jruggle]

Hi everyone,

I am getting pretty close to a new release for Aften. I thought I would post here because I have made what I think are some pretty good changes. The best one has to be the bandwidth filter. I was previously skeptical, but I tried it anyway since the Dolby guidelines recommend it. It makes a substantial difference in the high frequencies, and I don't even have a good ear for those kind of things. To hear for yourself...try encoding this sample (http://www.xiph.org/vorbis/listen/41_30sec.wav) at 192kbps. I have been using it quite a bit for testing because it has lots of dynamic range and prominant cymbals. I suspect many of you will have to wait for a Windows binary release...sorry. I will get a cross-compile environment setup one of these days.

The details of what I have done and what I have left before releasing version 0.04 are on my Aften development blog (http://aftenblog.blogspot.com/).

Thanks,
Justin

[raquete]

jruggle,
thanks for Aftenblog news (short-term plans,Bandwidth stuff and everything)

i download the sample that you posted and after hear i need to do (again(and again) the same answer that i posted in some threads in the audio forum and in this thread:
http://forum.doom9.org/showpost.php?p=856483&postcount=103

...
Dialogue Level:
Action Film -27 dB, Drama -27 dB, Local News -20 dB, Music -15 dB, Live Sporting Events -18 dB.

i still have to follow the SomeJoe's guide for audio-dvds(music only) ? :confused:

why i'm asking the same again?
...because your sample is too loud and is clipping :p
and if later is used to encode AC3 ...

regards.
;)

[BigDid]

...Dialogue Level:
Action Film -27 dB, Drama -27 dB, Local News -20 dB, Music -15 dB, Live Sporting Events -18 dB...

Hi,

So if I use -27db instead of default -31db, I increase the dialogue level of 4db?

Why do I ask? because
- I'm noob/dumb/difficult learner in audio ;)
- I reencode Ac3 audio cause in actual movies audio is often with too much expansion (for me) and dialogues are too low.
ATM I use Behappy input NicAudio with DRC/Normalize/ output to ac3-ffmpeg 448-> 384/320; 384-> 320.
I sure would like to use aften instead cause it is very promising.
I cannot use aften in Behappy unless Dimzon fixes the aften interface (I have asked for it but he has no time atm) so I will try converting to wav with behappy than back to ac3 with aften unless...

@jruggle, thanks for the good work.
Would it be possible/doable to make a special aften release for BeHappy (until fixed by Dimzon) that convert the aften bp/s to Behappy kbp/s? ie aften 320.000(bp/s), being converted to 320(kbp/s) for Behappy... It seems the only bug given by Tebasuna...
I may be wrong on that matter so maybe wait for reactions from authorised persons: Kurtnoise, Tebasuna, others?

Did

[jruggle]

So if I use -27db instead of default -31db, I increase the dialogue level of 4db?
If I understand your question right...no. The dialnorm setting does not affect the audio at all, only how it is decoded. You are just telling the decoder what the dialog level is. If you set the dialog level at, say -27, the decoder will actually turn down the volume by 4dB to "normalize" it to -31. This way all dialog is presented at around the same volume level when switching programs (i.e. movie to commercial).

@raquete
As far as dialnorm for music. I think it depends on what you define as "dialog". If there is singing, maybe find a section where the singing is prominant and measure the RMS of that. Really, unless it is being broadcast side-by-side with other AC-3 streams or you plan to add dynamic range control, it isn't much use to change the dialnorm. The listener will adjust the volume to a comfortable level.


@jruggle, thanks for the good work.
Would it be possible/doable to make a special aften release for BeHappy (until fixed by Dimzon) that convert the aften bp/s to Behappy kbp/s? ie aften 320.000(bp/s), being converted to 320(kbp/s) for Behappy... It seems the only bug given by Tebasuna...
I may be wrong on that matter so maybe wait for reactions from authorised persons: Kurtnoise, Tebasuna, others?
I guess if a majority of people agree, I can change Aften to use kbps instead of bps in release 0.04. I'm not particularly attached to doing it one way over the other. If it will be simpler to use kbps I have no problem changing it.

-Justin

[tebasuna51]

I cannot use aften in Behappy unless Dimzon fixes the aften interface (I have asked for it but he has no time atm) so I will try converting to wav with behappy than back to ac3 with aften unless...
You can use previous BeHappy version and aften.extension (http://forum.doom9.org/showthread.php?p=851058#post851058) in BeHappy folder. You can select only the bitrate, but if you want any other parameter, edit aften.extension lines before run BeHappy:
<Value>-b 320000 - "{0}"</Value>
and put your required parameters, for instance:
<Value>-b 320000 -dnorm 27 -v 0 - "{0}"</Value>

[BigDid]

@jruggle, thanks for the answer and the proposal for the 0.04. If done I apology to Kurtnoise who will have to change his GUI :o

@Tebasuna, I'll give it a try at home with everything at hand but I am a kind of dumb with commands and command line (had a hard time with avs/avsi at first) :( Thanks anyway for the proposal.
Now i understand why you didn't push Dimzon, you could do it that way :)

Did

[tebasuna51]

why i'm asking the same again?
...because your sample is too loud and is clipping
and if later is used to encode AC3 ...
There are a problem with jruggle sample but it isn't related with Dialog Norm.

Encoded with Aften (last binary from Kurtnoise), ffmpeg or SoftEncode (and with dnorm 17 or 31), when is decoded to wav with NicAc3Source (Bepipe/BeHappy) crash, and decoded with BeSweet-Azid there are more than 20 errors like:
[00:00:13.235] W7: Downmix overflow (0: +1.7dB)

The players work fine and I can't listen differences or clipping.

I wait for a new windows binary (maybe Kurtnoise is in holidays) to test the new bandwidth methods.

[jruggle]

There are a problem with jruggle sample but it isn't related with Dialog Norm.

Encoded with Aften (last binary from Kurtnoise), ffmpeg or SoftEncode (and with dnorm 17 or 31), when is decoded to wav with NicAc3Source (Bepipe/BeHappy) crash, and decoded with BeSweet-Azid there are more than 20 errors like:
[00:00:13.235] W7: Downmix overflow (0: +1.7dB)

The players work fine and I can't listen differences or clipping.

Now that is strange! That sample is just a regular wav file... It is one of the clips used in the vorbis listening tests. Maybe the problem is a decoder thing. What other settings are you using?

On another note. I have redone the configure/build system and made a separate libaften. It does not produce a .dll right now, only a static lib, but it will eventually. I will leave aften-current.tar.bz2 alone for a few days to allow for some testing before releasing version 0.04.

-Justin

[raquete]

@ jruggle and tebasuna51
Now that is strange! That sample is just a regular wav file...
There are a problem with jruggle sample but it isn't related with Dialog Norm.i was talking about the "sample .wav".
i mean "clipping" as "more than 100%(0db),i got big red bars in audition using the sample .wav,then,i don't encode this source for test.

As far as dialnorm for music. I think it depends on what you define as "dialog". i don't define,this is the hard doubt,i'm lost.
if i use -31 sounds too loud,using -16(value found using my source following SomeJoe sticky is -16.5) sounds poor,without "life"...
do you have recommendations to encode AC3 musics?
edit i don't use decoder/receiver but 6 channels amplifiers with dvdplayer Dolby Digital 5.1 decoder built in.

ps: adjusting in AftenGui dialogue normalization 0(zero) means "none" ?

thanks.
:)

[Rockaria]

Disclaimer : I am here just to exchange the facts and opinions audio specific, not for any boaring artificial attempts. Also any corrections will be appreciated.

That 2ch wav file is just max-gained, the peaks with no sign of clipped or hard-limited when expanded in Audacity, also played all-green(no red) with no attenuations on the channels. Some misinterpretations in the utils might have caused the clippings.

My understanding on the dialnorm is that it is used to normalize the listening environment(not to be deaf or frigntened) when switching between the clips or channels(sources) on Dolby decoders(receivers) based on the average volume level of (relative) signals that we call or define as 'dialogue' in Dolby clips.

The dialogue measured signal will be finally attenuated(adjusted) to the traditional (quiet) -31dB in the Dolby players/decoders/receivers based on the given relative meta value.

As used in most dd live solutions, the -31dB dialnorm won't adjust the decoding time dialogue level, and I guess the focus on the DRC and the volume knob(or album normalization) will be more useful if we consider the overall clarity and even volume level within/between(especially dolby/non-dolby preprocessed) the source(s).


In general there can be no default setting for dialnorm; the value depends on the nature of the program, and in the context of mixed programming it is essential for the setting to change from item to item. For a channel with uniform material, a fixed (but appropriate) setting may be acceptable. Generally a setting for dialnorm of -31 is unusual, required only for a few unprocessed wide-range movie soundtracks. For typical broadcast material (speech and popular music), the setting lies more often in the range of -15 to -20.
http://web.archive.org/web/20040716131627/http://www.dolby.com/tech/L.mn.0002.DDPEG1.pdf

[tebasuna51]

i was talking about the "sample .wav".
i mean "clipping" as "more than 100%(0db),i got big red bars in audition using the sample .wav,then,i don't encode this source for test.
A integer wav like the sample can't have more than 100%(0db). Is a maximized wav (or normalized at 0 dB) with peaks at 0 dB.

if i use -31 sounds too loud,using -16(value found using my source following SomeJoe sticky is -16.5) sounds poor,without "life"...
do you have recommendations to encode AC3 musics?
Using -31 or -16 the signal is encoded at 100%, with -31 the decoder is instructed to don't attenuate and with -16 the decoder is instructed to attenuate 15 dB.
Using -31 the volume is similar to modern music CDAudio, mp3 normalized 100%, commercials in TV, ...
Using -16 the volume is similar to others ac3 Dolby compliant.
You always can turn the volume of your amplifier down or up.

ps: adjusting in AftenGui dialogue normalization 0(zero) means "none" ?
Means 0 dB (the decoder attenuate the signal until -31 dB).

[Rockaria]

Then now the baseline is :
. the attached sample wav with max-gain should have no problems in ac3 encoding & decoding
. the SomeJoe's and Dolby's dialnorm explanations are basically SAME with slight different expressions
?

[raquete]

That 2ch wav file is just max-gained, the peaks with no sign of clipped or hard-limited when expanded in Audacity, also played all-green(no red)
A integer wav like the sample can't have more than 100%(0db). Is a maximized wav (or normalized at 0 dB) with peaks at 0 dB.
the attached sample wav with max-gain should have no problems in ac3 encoding & decoding

or my eyes and ears are too bad,or audition or ... the sample (lol)

look in all screenshots the bar levels in red(clip) after 0dB.
whole sample wav playing:
http://img110.imageshack.us/img110/1157/sampleclippingbd5.th.png (http://img110.imageshack.us/my.php?image=sampleclippingbd5.png)

clipping in right channel 0:04.321
http://img110.imageshack.us/img110/5872/clip1ez4.th.png (http://img110.imageshack.us/my.php?image=clip1ez4.png)

clipping in left channel 0:14.356
http://img105.imageshack.us/img105/1663/clip2cq4.th.png (http://img105.imageshack.us/my.php?image=clip2cq4.png)

clipping (double) in left channel 0:28.840 and 0:28.841
http://img105.imageshack.us/img105/1472/clip3wx7.th.png (http://img105.imageshack.us/my.php?image=clip3wx7.png)

don't have sound in the blue lines! ? :confused: (zoom the pictures if needed)
more than 0dB and audition can't show it?

You always can turn the volume of your amplifier down or up.
yes,it change the volume but...
For typical broadcast material (speech and popular music), the setting lies more often in the range of -15 to -20.
... it don't change the quality of the sound.the problem is: or low and faded at -16,or too loud and crispy at -31.
both sounds ugly!

Means 0 dB (the decoder attenuate the signal until -31 dB). all right.

about the sound: i hear the cymbals too crispy,seems(are)...shiver.
please,comments about "everything" will be appreciated(about my ears include).

thank you boys,you are very specials in the team!
:)

[Rockaria]

Hi raquete,

The audacity expanded images(by the appearance) clearly show the symptoms of the clipped wav forms to me also, so you don't have to worry about your EYES.
The problem still remaining is there can be some different interpretations(although I expressed as mis-) between the tools.
So I tested with one more popular FREE tool : foobar2k v0.92->replaygain scan!
name : 41_30sec
track peak : 0.999969
track gain : +0.54dB

So it is not max-gained yet(0.54dB gain room left) and the issue seems to be which tools to use not to have the clips clipped.

[edit] I notice the proportional variable dB scales on the Y-axis making it hard to assume the 0dB positions. Maybe you need to change the scale view.

[raquete]

so you don't have to worry about your EYES.
lol. now about my ears,audition and the sample...

Maybe you need to change the scale view. done.

http://img311.imageshack.us/img311/8265/clip2aww2.th.png (http://img311.imageshack.us/my.php?image=clip2aww2.png)

(zoom please)...the thin blue line is in 0dB.the sound after the blue line is above 0dB.

about the sound: i hear the cymbals too crispy,seems(are)...shiver.
as i hear and audition advice that the sound is clipping,i can trust in my ears and in audition too.
:p
trust,when i was playing the sample my first impression was the sound quality("crispy" as i posted)

thanks!

edit: see the bargraph in the pictures showing clips in red (full scale)

http://img403.imageshack.us/img403/2471/clip4gs0.png
in this post http://forum.doom9.org/showpost.php?p=858952&postcount=121

[Rockaria]

Oh yes, I now find the two clipped out-of-phase positions @ : 14.35700 & 14.35710, :thanks:
I assume the audacity's(and foobar 2k, ffdshow...) interpretation & expression : hard-limit on the 0dB, the audition's one : rebuild the clipped area.

Maybe we can say the audition is more intelligent but artificial as well. So it also depends on the personal interpretations?
I personally think in my environment, it has very little(ignorable) negative effect to be used as a transcoding/playing source...

[jruggle]

Hi,
I need a favor. :)
I am trying to setup a cross-compile environment so that I can build Windows binaries for others to use. Could someone test these executables to see if either works?

aften.exe (http://jbr.homelinux.org/aften/aften.exe)
aften_g.exe (http://jbr.homelinux.org/aften/aften_g.exe)

Thanks!
-Justin

[Rockaria]

Both work (correctly) with -b mode but not correctly in -q mode.
i.e, aften -b 640000 -m 0 -acmod 2 41_30sec.wav aaa1.ac3
...
. no effect in -m mode change
. waiting for the v0.04 window version.

P4, Xp Pro, MPC with ffdshow...

Thanks.

[jruggle]

Both work (correctly) with -b mode but not correctly in -q mode.
i.e, aften -b 640000 -m 0 -acmod 2 41_30sec.wav aaa1.ac3
...
. no effect in -m mode change
. waiting for the v0.04 window version.

Thank you for the feedback. I'm just glad it works at all (runs).

What do you mean by "not correctly in -q mode"? Does it produce an ac3 file, but it just doesn't decode right? or does it crash when you're encoding?

I'm hoping that "no effect in -m mode" means that the file isn't much different, not that the output file is bit-identical. The sample file doesn't have a lot of channel correlation, so I would expect rematrixing not to do much...if it doesn't do anything at all that's a bug.

As far as version 0.04...that was pretty much it. Unless I run into any major bugs I need to fix, the current version will become 0.04 in a day or two. The VBR problem worries me...but I'll wait for more feedback before freaking out. ;)

Thanks again,
-Justin

[tebasuna51]

@jruggle
Your windows binary work ok.

I tried the test suggested in aftenblog with:
aften -b 192000 -w -1 -bwfilter 0 41_30sec.wav z41_-1_0.ac3
aften -b 192000 -w -1 -bwfilter 1 41_30sec.wav z41_-1_1.ac3
aften -b 192000 -w -2 41_30sec.wav z41_-2.ac3
but my ears can't find any difference, sorry.

[Rockaria]

What do you mean by "not correctly in -q mode"? Does it produce an ac3 file, but it just doesn't decode right?
Exactly.. When I verified the encoded ac3 with softencode, it was normal. But it always showed wrong but different playbacks if I change the -q values.

The -m mode change with CBR had no effects on the bit rate of course, but also I could hardly notice the quality differernce(to measure this short clip to my ears).
When used with the VBR(-q), I guess it will clearly show the bit efficiency...

[jruggle]

@jruggle
Your windows binary work ok.

I tried the test suggested in aftenblog with:
aften -b 192000 -w -1 -bwfilter 0 41_30sec.wav z41_-1_0.ac3
aften -b 192000 -w -1 -bwfilter 1 41_30sec.wav z41_-1_1.ac3
aften -b 192000 -w -2 41_30sec.wav z41_-2.ac3
but my ears can't find any difference, sorry.

wonderful! thank you.

I gave the test a fresh listen just to reassure myself that it wasn't a placebo effect. I did still notice a difference. However, I also realized that the variable bandwidth cutoff ended up quite a bit less than the fixed adaptive bandwidth, so I tried the test with "-w 32 -bwfilter 1". I still noticed a difference...enough to convince me, but I really need to get or make a working ABX test program so I can be less subjective about it.

Anyway, I'm excited that my cross-compile worked. Version 0.04 will be released, probably on Saturday, as both source and binary.

[raquete]

from 42_DDFAQ.pdf (Dolby Inc.)
"Dolby Digital can process up to 24-bit digital audio signals over a frequence range from 20Hz to 20KHz on the full-range channels..."

Aften can encode 20 or 24bit? if don't,...why not as new feature for test?
(if yes,let me out to buy some fireworks :p )

thanks! ;)

ps: anyone is testing/using VBR?

[jruggle]

from 42_DDFAQ.pdf (Dolby Inc.)
"Dolby Digital can process up to 24-bit digital audio signals over a frequence range from 20Hz to 20KHz on the full-range channels..."

Aften can encode 20 or 24bit? if don't,...why not as new feature for test?
(if yes,let me out to buy some fireworks :p )

Actually the format can do more than that. I think the doc from Dolby is referring to what Dolby certified encoders are required to do.

Aften can handle 8-bit/16-bit/24-bit/32-bit/float/double wav input. All of these are converted to double-precision floating point samples, which is what libaften expects as input. The encoder runs the MDCT in floating-point then quantizes the coefficients to the AC-3 internal floating-point format (separately coded exponents and mantissas). The exponents do allow for a full 24-bit range. Actually it's more like 25-bit, but I won't get into that. Any precision above that just gets lost in the quantization...it is a lossy codec after all.

One thing I can add is 20-bit wav support (or 17 or 12 or whatever). This should not be too difficult.

ps: anyone is testing/using VBR?
I am considering relegating the VBR mode to non-default until I can do more testing myself or get lots of feedback. The default CBR bitrate will depend on the number of full-bandwidth channels being encoded. I'm thinking:
1 = 96kbps
2 = 192
3 = 256
4 = 384
5 = 448

If I decide to make VBR default again it will depend on DVD/HD-DVD/Blu-ray support (actual, not spec). If players will play it, then it should get more use and be the default...otherwise it will still be there for those who wish to use it.

[BigDid]

The default CBR bitrate will depend on the number of full-bandwidth channels being encoded. I'm thinking:
1 = 96kbps
2 = 192
3 = 256
4 = 384
5 = 448

Hi,

Please consider adding 320 for CBR, as it is in the specs (from a Tebasuna post): http://forum.doom9.org/showthread.php?p=854685#post854685
and a multi-channels compromise between 384-good- and 256-acceptable to bad- (I have been told). Thanks.

Did

[Rockaria]

That looks like enough CBR bit rates for backup purposes. I also think the 64k increments from the full 2ch(2.x~) as default bit rates looks more reasonable.
My previous feedbacks were for just brief verification that it runs on Xp. Now I did some more tests and analysis on the below result which might be useful before the release of v0.04.
Encoded with Aften (last binary from Kurtnoise), ffmpeg or SoftEncode (and with dnorm 17 or 31), when is decoded to wav with NicAc3Source (Bepipe/BeHappy) crash, and decoded with BeSweet-Azid there are more than 20 errors like:
[00:00:13.235] W7: Downmix overflow (0: +1.7dB)
<condition>
. 44_30sec.wav 2ch wav source : has some soft clippings(around 10(20?)~) not noticeable(to me)
. also tested with another 2ch wav(no clippings) and 6ch wav to verify
<results>
. softencode gave no warning, encoded & decoded well
. aften encoded (well) with no warning but failed to play resonably on -q mode encodings : both 2ch & 6ch
- aften encoded 2ch clips failed to decode with nicac3source avisynth plugin regardless of the clippings : 6ch is ok
<conclusion>
. 2ch encoding issue : compatibility problem in some decoders
. -q mode issue : seek or sync problem ?, not proper decoding(&encoding)
. clipping issue in decoding/reading : some tools(like audition) are rebuilding the clipped area, may require some pre-gaining(~-3dB) process when you get warnings.

[edit]
The NicAc3Source avisynth plugin(the original version) also failed to play the softencode encoded 2ch ac3 regardless of the clippings.
So it seems not the aften's problem.

[raquete]

jruggle

Aften can handle 8-bit/16-bit/24-bit/32-bit/float/double wav input.
of course,i know and use. i used 2 big sources(.wav 6-channels 48000Hz, 32-bit with 3,24Gb 50:25.200 and 3,19Gb 42:340.360)in Aften and works great!
i want to know about AC3 48K 20 or 24 bit output. :stupid:

I'm thinking:
1 = 96kbps
2 = 192
3 = 256
4 = 384
5 = 448
Please consider adding 320 for CBR, as it is in the specs
I also think the 64k increments from the full 2ch(2.x~) as default bit rates looks more reasonable.
jruggle,i encode min 512K,sometimes 640K...always 5.1(never 2.0)
please,extend the list, don't forget me. ;)

best regards and thanks for explanations.

[Rockaria]

he he! I forgot the conditions(and those are just default values per -acmod that can be overridden).;)
When the 'rematrixing, channel coupling and optionally VBR/ABR' get extremely effective/efficient as intended, it won't need that much bit rates to please your sensitive ears. I personally prefer no transcoding at home though(I use 6ch 640k dd live for the codec compatibility to my receivers).

raquete, you are one big AC3 fan and will never be forgotten by jruggle, I bet.:cool: :)
/me on a long travel.

[tebasuna51]

[edit]
The NicAc3Source avisynth plugin(the original version) also failed to play the softencode encoded 2ch ac3 regardless of the clippings.
So it seems not the aften's problem.
Yes, but i think is a NicAc3Source problem with 44.1 KHz, not with 2 or 6 channels. Can you confirm this with your samples?.
HPlease consider adding 320 for CBR, as it is in the specs (from a Tebasuna post): http://forum.doom9.org/showthread.php?p=854685#post854685
and a multi-channels compromise between 384-good- and 256-acceptable to bad- (I have been told)
I agree with defaults proposed by jruggle, you can use 320 or any other valid value in command line.

[BigDid]

defaults[/B] proposed by jruggle, you can use 320 or any other valid value in command line.
Hi detractors :)

I have already stated I am really not at ease with command line apps :o

@ jruggle
[blatant advertising on]
Please imagine all the potential AC3 encoding people (hundreds, surely thousands) just waiting to learn there is a free and performant tool available, either directly, with a GUI or included in a powerfull all-in-one audio app (Behappy).
I'm sure the first reaction will be:
-Is it easy to use? -> Yes there is a GUI
-Can I do more but still with a GUI -> Yes with Behappy
[blatant advertising off]

Specialists are praising your tool; I believe it's just a matter of time before non-specialists will also use it.
Don't forget the "PAY PAL donate" button and the 320-CBR :D

Did

[Rockaria]

Yes, but i think is a NicAc3Source problem with 44.1 KHz, not with 2 or 6 channels. Can you confirm this with your samples?.
Is it a known problem? If not, it must be a small but useful discovery by us all.

Indeed, the previous 6ch clip was 48k, so I made 2 wav files to test it fully: 48k 2ch wav & 44.1k 6ch wav
==>All the 44.1k ac3 encoded crashed with NicAc3Source, but 48k played OK regardless of the channels(-acmod).

Some other things that may require your confirmations :
. I interpreted the audition performs 'rebuilding' on the clipped area making it to have wider range(beyond 0dB), you may be able to confirm the BeSweet-Azid if it becomes OK with -3dB pre-attenuated 44_30sec.wav. (the attenuation option might be useful for aften)
. the behappy environment(avs wrapper) seems to downsize(16bit) the avs input stream making the aften's wider input capability an overkill, you might have the latest source to confirm.
. some other things not related to aften...

/good to share

[jruggle]

jruggle
of course,i know and use. i used 2 big sources(.wav 6-channels 48000Hz, 32-bit with 3,24Gb 50:25.200 and 3,19Gb 42:340.360)in Aften and works great!
i want to know about AC3 48K 20 or 24 bit output. :stupid:

Ah...well Aften is not a decoder, but the AC3 files produced by Aften can take advantage of the full AC3 accuracy range...depending on the depth of the source material. Or am I misunderstanding your question...?


jruggle,i encode min 512K,sometimes 640K...always 5.1(never 2.0)
please,extend the list, don't forget me. ;)

You can still encode at 512 or 640. I chose 448 as default because that is what Dolby recommends for 5.1 content.

As far as the issues with that sample I've been using...I didn't notice the clipping before, so maybe I should find a better sample to use.

I don't think that Aften should do any fancy audio processing (clipping rebuild/attenuation). I'll leave that up to the professional audio apps. I do hope to provide resampling though, as it will be a huge benefit to those needing 48kHz for DVD (and apparently NicAc3Source) compatibility.

Thanks,
Justin

[tebasuna51]

. I interpreted the audition performs 'rebuilding' on the clipped area making it to have wider range(beyond 0dB), you may be able to confirm the BeSweet-Azid if it becomes OK with -3dB pre-attenuated 44_30sec.wav. (the attenuation option might be useful for aften)
I make a previous test at 80% (-2dB) without Azid warnings. But this levels of clip at a few peaks don't affect the overall quality.
. the behappy environment(avs wrapper) seems to downsize(16bit) the avs input stream making the aften's wider input capability an overkill, you might have the latest source to confirm.
With AviSynth 2.57 (alpha) and Bepipe i make some test, and work with 32 bit wavs (int and float). From 2.57 docs:
* WavSource() accept audio streams of type WAVE_FORMAT_IEEE_FLOAT.
* Adding global OPT_AllowFloatAudio=True to your script enables WAVE_FORMAT_IEEE_FLOAT audio output.

[Rockaria]

Then the Besweet-azid seems to perform kinda 'rebuilding' on decoded ac3 encoded originally clipped area(or some other interpretations on the streams).

I am less familiar with the behappy wrapper than the original open avisynth environment.
So you can regard I am well aware of the avisynth's wide range capability of the bit sizes.
However, in the older(20060226) source of the AvisynthWrapper.cpp I read :

if (inf.HasAudio())
{
*originalSampleType = inf.SampleType();
if( *originalSampleType != SAMPLE_INT16)
{
res = pstr->env->Invoke("ConvertAudioTo16bit", res);
pstr->clp = res.AsClip();
infh = pstr->clp->GetVideoInfo();
if(infh.SampleType() != SAMPLE_INT16)
{
strncpy(pstr->err,"Cannot convert audio to 16bit",ERRMSG_LEN-1);
return 6;
}
}
}
which forces any audio stream process beyond 16bit not that useful including aften ac3 encoder through pipe.
There might be some reasons for this restriction or already excluded(which I cannot confirm) that behappy users with aften certainly want?
(I am not sure if this issue is discussed already)

Thanks.
[edit] I confirm the latest cpp source dated 05/09/2006 is unchanged in the mentioned area.

[jruggle]

I made the bitrate changes that have been discussed. This is the final change before the release of v0.04 tomorrow.

changes: CBR is default. Bitrate is given in kbps. Also, you can use both '-b' and '-q' to encode VBR with a maximum bitrate.

[raquete]

Or am I misunderstanding your question...?
Justin
maybe ...is my fault,excuse me(poor english and lots of typos)

first
what i do:
load any cd track,convert sample type 48k-32bit,extract center and surrounds,save this all (LR,CLFE and SLSR) as "32 bit normalized float(type 3) default" in adobe audition.
load this tracks in multichannel encoder and "export as one interleaved,6-channels wave file" windows PCM waveform audio - 32bit,normalized float (type 3) or as 32 bit,4-byte integer (type 1).
(sometimes exporting 32bit,normalized float (type 3) in audition give some clicks, then i export as 32 bit,4-byte integer (type 1) )
...i take this "one interleaved,6-channels wave file" to AftenGUI to get AC3 5.1 512K.

second:
now my answer (after this big road) and i'm not sure if this is possible or if works:
can Aften encode this AC3 5.1 512K in 20 or 24 bit?

thanks Justin
;)

[jruggle]

can Aften encode this AC3 5.1 512K in 20 or 24 bit?

I see. The short answer is "there is no such thing". :)

AC3 does not have a specific bit depth. The closest thing to it would be something like 21-bit floating-point. AC3 uses an exponential floating-point format with an exponent of 0 to 24 and a 0-bit to 16-bit variable-depth mantissa. This sort of means that it has the precision of 16-bit, but the range of 24-bit. Also, what is encoded is in the frequency-domain, not in the time-domain like wav.

I hope this answers your question.

-Justin

[raquete]

I see. The short answer is "there is no such thing". :)

AC3 does not have a specific bit depth. The closest thing to it would be something like 21-bit floating-point. AC3 uses an exponential floating-point format with an exponent of 0 to 24 and a 0-bit to 16-bit variable-depth mantissa. Also, what is encoded is in the frequency-domain, not in the time-domain like wav.

I hope this answers your question.

-Justin
(...living and learning)

thank you so much Justin,very clear.
:)

[Kurtnoise]

ouchhi. One week of vacation and some new stuff is already here. Great...:)

So, I uploaded a fresh compile here (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften-0.03-dev.zip). I'll update the GUI as soon as 0.04 will be release. (I hope before Monday coz I go back in holidays next week...;))


@Justin : for -bwfilter/dcfilter/lfefilter in the command help, which value is default ? For the moment, both values (0/1) are sticked as default...Sorry, I've no time to check the code carefully.


@BigDid : ac3 <--> ac3 is useless imo. Keep in mind that this is a lossy format. And I really don't know why you reencode your audio stream coz dvds/cds are more and more cheaper nowadays.

[jruggle]

Glad to see you back Kurtnoise.


So, I uploaded a fresh compile here (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften-0.03-dev.zip). I'll update the GUI as soon as 0.04 will be release. (I hope before Monday coz I go back in holidays next week...;))

It will be later today (US Eastern time).


@Justin : for -bwfilter/dcfilter/lfefilter in the command help, which value is default ? For the moment, both values (0/1) are sticked as default...Sorry, I've no time to check the code carefully.

oops! will be fixed in 0.04. The default is 0 (no filter).

[BigDid]

@BigDid : ac3 <--> ac3 is useless imo. Keep in mind that this is a lossy format. And I really don't know why you reencode your audio stream coz dvds/cds are more and more cheaper nowadays.
Hi Kurtnoise and happy holidays,

We have had that kind of exchange in the past but you're the expert, so I will try to argument:
It's not ac3->ac3 for pleasure it's for:
1. playing multichannels audio on a SAP (AAC or OGG not playable on most models)
2. getting the low sound/dialogs (or too much expansion) to a better listening level.
3. Cheaper DVD media are yet to arrive here, but I can't have the butter ... and so on

I know, from other threads like Behappy that some people, like me, wants to DRC/normalize for reason 2. I also use a higher bitrate than before (384 or 320) to keep more bandwidth so, at least, some of your advices are getting through :D

Did

[raquete]

@ Kurtnoise13
So, I uploaded a fresh compile here. is not working with AftenGui...:(
I'll update the GUI as soon as 0.04 will be release.great. :cool:
happy holidays and thanks(so much). ;)

but you're the expert, so I will try to argument:...
do that...smash (massacre) soft encode head! :p

regards.

[Rockaria]

(...living and learning)

thank you so much Justin,very clear.
That's very true. You are not the only one(include me). And it's rather a frequently misunderstood/confused fact.
So virtually ~24bit(21 float depth). SPDIF (the ac3 carrier) also has the same(20~24) but phsical limit and often confused with ac3's one.
The soundstorm(a dd live solution, I have 5 boards) is said to DD Live encode to 24(or 20)bit also @48k, 640kbps. So I set the player output to 24bit depth when using the system mixer(DD Live). But for the player dynamic ac3 encoding output(ac3filter, ffdshow...), there seem to have been no/few upsizing DSP beside relying on the decoder/source resolution, which is not that bad though.

Woosh! Exponents & Mantissa is so confusing.. do I even need to know that?:rolleyes:
/on a real travel monday..

[jruggle]

Aften version 0.04 is now available.

** on the Aften Sourceforge project page (http://sourceforge.net/projects/aften) **

:)
-Justin

[danpos]

@jruggle

Thanks for new release, mate. :)

Keep up the good work.

Regards,

[Rockaria]

As I started it.:) : now the -q mode DECODER issue

<encoding>
aften -q 1023 -acmod 2 41_30sec.wav aaa1.ac3
aften -q 512 -acmod 2 41_30sec.wav aaa2.ac3

<decoding>
It varies by the decoders : some displayed correct VBR info and ffdshow only failed to display & play resonably.

. ac3Filter 1.01a RC5 plays well but says on both clips : 44.1k stereo 640kbps 2786B framesize
. ffdshow(0526, 2006) plays as CBR(faster with the lower -q) and says on both something like : 44.1k, stereo 635kbps ac3
. foobar2k v0.83 plays well and says : 44.1k, 2ch, 384/320kbps
. softEncode also displays perfect clip informations : 384/320kbps

<<softEncode>>
File: C:\My Music\aaa1.ac3
File size: 2,397,068 bytes
AC-3 File type: Non-Intel byte order (0x0b)
Total frames: 861
Frame size: 1,670 bytes
Sample rate: 44,100 Hz
Data rate: 384 kbps
Audio coding mode: 2/0 (L, R)
Bit stream mode: Main audio service: Complete main
Dialog normalization: -31 dB
Center mix: None
Surround mix: None
Copyright: Off
Original: On
Start time: 00:00:0.00 *
End time: 00:00:29.99
Status: No errors were found

File: C:\My Music\aaa2.ac3
File size: 2,395,676 bytes
AC-3 File type: Non-Intel byte order (0x0b)
Total frames: 861
Frame size: 1,392 bytes
Sample rate: 44,100 Hz
Data rate: 320 kbps
Audio coding mode: 2/0 (L, R)
Bit stream mode: Main audio service: Complete main
Dialog normalization: -31 dB
Center mix: None
Surround mix: None
Copyright: Off
Original: On
Start time: 00:00:0.00 *
End time: 00:00:29.99
Status: No errors were found

<<ac3Filter 1.01a RC5>>
<aaa1.ac3>
AC3
speakers: 2/0 (stereo)
sample rate: 44100Hz
bitrate: 640kbps
stream: 8 bit
frame size: 2786 bytes
nsamples: 1536
bsid: 8
clev: 0.0dB (1.0000)
slev: 0.0dB (1.0000)
dialnorm: -31dB
bandwidth: 21kHz/21kHz

<aaa2.ac3>
AC3
speakers: 2/0 (stereo)
sample rate: 44100Hz
bitrate: 640kbps
stream: 8 bit
frame size: 2786 bytes
nsamples: 1536
bsid: 8
clev: 0.0dB (1.0000)
slev: 0.0dB (1.0000)
dialnorm: -31dB
bandwidth: 21kHz/21kHz


<<foobar2k v0.83>>
<aaa1.ac3>
bitrate = 384
codec = ATSC A/52
channels = 2
samplerate = 44100
----------
2202306 samples @ 44100Hz
File size: 2 397 068 bytes

<aaa2.ac3>
bitrate = 320
codec = ATSC A/52
channels = 2
samplerate = 44100
----------
2641233 samples @ 44100Hz
File size: 2 395 676 bytes

Sorry,.. no further details on FFDShow

/Good work.

[tebasuna51]

The aften windows binary from jruggle and last from Kurtnoise don't work with standard-input from Bepipe/BeHappy.

@Rockaria, I locate the bug in NicAudioAc3 with 44.1 KHz., more about this in BeHappy thread.

[Rockaria]

@Rockaria, I locate the bug in NicAudioAc3 with 44.1 KHz., more about this in BeHappy thread.
Thanks, I read it. As I recognize you as the behappy environment speaker;), I am leaving it upto you including the other issue(wrapper).

BTW, the version I tested with was the original Nic's version. So if the new release(with DRC enabled) does not completely replace the original version yet, I believe mentioning in a same place(i.e. avisynth section) looks proper..

[jruggle]

The aften windows binary from jruggle and last from Kurtnoise don't work with standard-input from Bepipe/BeHappy.

dang! well, it should be fixed now in current svn. I will look into providing a nightly build separate from the versioned releases. In this case...I think it warrants a bugfix release if I have indeed fixed the problem.

try this binary (http://jbr.homelinux.org/aften/aften.exe) to see if it works.

thanks for the info.
-Justin

[tebasuna51]

try this binary (http://jbr.homelinux.org/aften/aften.exe) to see if it works.
Yes, it work fine with Bepipe and last BeHappy version.

Thanks.

[raquete]

try this binary to see if it works.
is not working in AftenGUI(like the last today from Kurtnoise13)and i back to "Aften-0.03-dev" 24-jul-06.

:thanks:

[Rockaria]

Hi boys and gentlemen,

One last(for somewhile) stats of the -m mode for the stereo clips only(again as I started it) looking for successive useful analysis from anybody.

I was unable to experience the shoking advantage of 'stereo rematrixing' with 41_30sec.wav, partially because of the less common factors and mostly because of the v0.04?
<enc.cmd>
aften -m 0 -q 100 -acmod 2 41_30sec.wav aaab10.ac3
aften -m 1 -q 100 -acmod 2 41_30sec.wav aaab11.ac3

aften -m 0 -q 200 -acmod 2 41_30sec.wav aaab20.ac3
aften -m 1 -q 200 -acmod 2 41_30sec.wav aaab21.ac3
...
<dir aaab*.ac3>aaab.lst>
...
.... 122,668 aaab10.ac3
.... 122,452 aaab11.ac3
.... 714,218 aaab20.ac3
.... 712,278 aaab21.ac3
.... 1,706,930 aaab30.ac3
.... 1,700,222 aaab31.ac3
.... 2,392,614 aaab40.ac3
.... 2,392,614 aaab41.ac3
.... 2,395,676 aaab50.ac3
.... 2,395,676 aaab51.ac3

So I made a dual mono 41_30dsec.wav to 'stereo-encode' and got somewhat different yet-to-resonate results based on the 'quality level : file size' comparison.
<enc.cmd>
aften -m 0 -q 100 -acmod 2 41_30dsec.wav aaaa10.ac3
aften -m 1 -q 100 -acmod 2 41_30dsec.wav aaaa11.ac3
...
aften -m 0 -q 900 -acmod 2 41_30dsec.wav aaaa90.ac3
aften -m 1 -q 900 -acmod 2 41_30dsec.wav aaaa91.ac3

<dir aaaa*.ac3>aaaa.lst>
...
.... 122,410 aaaa10.ac3
.... 121,120 aaaa11.ac3
.... 704,782 aaaa20.ac3
.... 475,174 aaaa21.ac3
.... 1,705,764 aaaa30.ac3
.... 1,143,886 aaaa31.ac3
.... 2,391,210 aaaa40.ac3
.... 1,743,146 aaaa41.ac3
.... 2,395,676 aaaa50.ac3
.... 2,157,404 aaaa51.ac3
.... 2,397,068 aaaa60.ac3
.... 2,273,222 aaaa61.ac3
.... 2,397,068 aaaa70.ac3
.... 2,312,304 aaaa71.ac3
.... 2,397,068 aaaa80.ac3
.... 2,312,304 aaaa81.ac3
.... 2,397,068 aaaa90.ac3
.... 2,312,304 aaaa91.ac3

reasonable same qualities for same -q levels to my ears
no other conclusions here. left for others & ABX tests.

[jruggle]

Hi boys and gentlemen,

One last(for somewhile) stats of the -m mode for the stereo clips only(again as I started it) looking for successive useful analysis from anybody.

I was unable to experience the shoking advantage of 'stereo rematrixing' with 41_30sec.wav, partially because of the less common factors and mostly because of the v0.04?

Thanks. I was just using the algorithm in the specification, but I did some modifications, and now the stereo rematrixing works a little bit better. The changes have been committed to SVN.

Also, I have created a cron job which will upload daily builds. They can be accessed at:
http://jbr.homelinux.org/aften/daily/
the .zip files are win32 binaries
the .bz2 files are source files

The job is set to run every day at 4:50AM EST. I already made some builds for today (6th) and yesterday (5th) as a test. The ones for the 6th will be overwritten at 4:30.

[Kurtnoise]

1st post and GUI updated (http://kurtnoise.free.fr/index.php?dir=Aften/&file=AftenGUI-1.2.zip). :)

@Raquete : AftenGUI 1.1 doesn't work with aften 0.03-dev and higher due to the bitrate tweaking (bps --> kbps). It should be fine now with the 1.2.



We have had that kind of exchange in the past but you're the expert, so I will try to argument:
C'est pas gagné...:p

I'm ok for #2 but this depends of your source. Regarding #1, this doesn't make sense, sorry. "Reencode an ac3 stream to have multichannel playback"...It's really funny imho. If it's not a pleasure for you, well don't reencode them. Don't waste your time with this, it's really precious for other things.

[Inc]

Then the Besweet-azid seems to perform kinda 'rebuilding' on decoded ac3 encoded originally clipped area(or some other interpretations on the streams).

I am less familiar with the behappy wrapper than the original open avisynth environment.
So you can regard I am well aware of the avisynth's wide range capability of the bit sizes.
However, in the older(20060226) source of the AvisynthWrapper.cpp I read :

if (inf.HasAudio())
{
*originalSampleType = inf.SampleType();
if( *originalSampleType != SAMPLE_INT16)
{
res = pstr->env->Invoke("ConvertAudioTo16bit", res);
pstr->clp = res.AsClip();
infh = pstr->clp->GetVideoInfo();
if(infh.SampleType() != SAMPLE_INT16)
{
strncpy(pstr->err,"Cannot convert audio to 16bit",ERRMSG_LEN-1);
return 6;
}
}
}
which forces any audio stream process beyond 16bit not that useful including aften ac3 encoder through pipe.
There might be some reasons for this restriction or already excluded(which I cannot confirm) that behappy users with aften certainly want?
(I am not sure if this issue is discussed already)

Thanks.
[edit] I confirm the latest cpp source dated 05/09/2006 is unchanged in the mentioned area.
That one was implemented by the orig author 'mobileHackerz' of avsredirect.dll on which avisynthwrapper does base on.
Its kinda forcing a compatibility as its original purpose was to serve avs frameservingdata to ffmpeg. Just alter that section or even mark it using "//", compile the dll using VSC++ Express 2005 and see what happens when using in Behappy etc. ;)

[BigDid]

Thanks for the new release(s), thanks for the compatibility with Behappy, thanks for the new GUI.

Did

[Rockaria]

That one was implemented by the orig author 'mobileHackerz' of avsredirect.dll on which avisynthwrapper does base on.
Its kinda forcing a compatibility as its original purpose was to serve avs frameservingdata to ffmpeg. Just alter that section or even mark it using "//", compile the dll using VSC++ Express 2005 and see what happens when using in Behappy etc. ;)Thanks, I am forwarding it to tebasuna. The reasons explained.;)
And thanks gents, I will check the daily builds whenever possible and demanding.

[raquete]

1st post and GUI updated.

@Raquete : AftenGUI 1.1 doesn't work with aften 0.03-dev and higher due to the bitrate tweaking (bps --> kbps). It should be fine now with the 1.2.
(AftenGUI v1.1 is working with aften 0.03-dev(24-07-06),i posted "samples" with this version today)
woo...thanks so much,the new AftenGUI is working fine( of course..you build it!) :cool:
now is full of features and adjusts ... :eek: ...i need one "guide" Kurt. :D (not kiddin)
someone please help me!
:thanks:

[DSP8000]

Hi,

Tnx. to everyone's effort in developing this encoder.
Here's an installer for Aften AC3 Encoder v0.5 Incl.GUI v1.2 (http://members.iinet.com.au/~isdmultimedia/files/Aften%20AC3%20Encoder%20v0.5.exe) by kurtnoise.

Keep up the good work :)


DSP8000

EDIT: UPDATED TO v0.5

[jruggle]

I invite anyone who is interested in the development side of Aften to join the aften-devel (http://lists.sourceforge.net/mailman/listinfo/aften-devel) mailing list.

[Kurtnoise]

now is full of features and adjusts ... :eek: ...i need one "guide" Kurt. :D (not kiddin)
Actually, you have just to concentrate on the "General" Tab for *Normal* encodes. All others depend of your needs.

[jruggle]

Version 0.05 released today.
Biggest improvement: 30-50% speed increase (depending on platform & CPU)

http://sourceforge.net/projects/aften/

[Mug Funky]

haha! that makes it ~ 15x faster than soft encode :)

[dragongodz]

jruggle - do you have any plans to try and get some of these changes in to ffmpeg/libavcodec ? that would be nice.

[raquete]

anyone is using short-block 256-point MDCT?

jruggle, :thanks: for the news.

[Mug Funky]

i'm using short blocks. haven't done any ABX'ing yet, but some samples with crackle, castanets and heavy brass don't sound obviously bad.

[jruggle]

jruggle - do you have any plans to try and get some of these changes in to ffmpeg/libavcodec ? that would be nice.
Yes, the recent speed-ups can be ported back to ffmpeg. Also there are a couple bug fixes.

[raquete]

Hi,

Tnx. to everyone's effort in developing this encoder.
Here's an installer for Aften AC3 Encoder v0.5 Incl.GUI v1.2[/URL] by kurtnoise.

Keep up the good work :)


DSP8000

EDIT: UPDATED TO v0.5
thanks. :goodpost:

ps: i was lucky finding the update.don't deserve a new post after each new version? ;)

[DSP8000]

ps: i was lucky finding the update.don't deserve a new post after each new version?

Yes, sure, no probs ;)

DSP8000

[Chainmax]

i'm using short blocks. haven't done any ABX'ing yet, but some samples with crackle, castanets and heavy brass don't sound obviously bad.

That sounds great, hopefully an organized listening test comparing Aften to commercial encoders will take place at HA soon.

[DSP8000]

Hi Guys,

Can someone make HTML Guide for Aften? I'd like to include it in my installer as a reference guide for Aften.
Also, @kurtnoise,
can you send me your GUI with 48x48 or higher res icon? Check your mail as well ;).

IMO, excellent AC3 encoder like Aften deserves a bit more attention, meaning,

avearge Joe will not understand short blocks, dialg norm,mid-side stereo...

We need full on guide with all of the settings explained.
From my tests so far I think Aften produces very good output :) .

DSP8000

[Kurtnoise]

@kurtnoise,
can you send me your GUI with 48x48 or higher res icon?
64x64 is ok ? :> http://kurtnoise.free.fr/cr64.png

[Mug Funky]

a possibility comes to mind (after reading DSP8000's comments about usability, lay users, etc):

- encoding and replaygain scanning can be done in 1 pass
- a very quick 2nd pass assigns dialnorm, mix level, and possibly DRC on the already encoded data using stats gathered from the 1st pass.

that way dialog normalization, mix level and DRC is always set properly without any need for the user to go find this information (which is often simply not available, even on the majority of DA-88 master tapes!)

just an idea... i'm hanging out for DRC mainly because, 5.1 coupling aside, it's the major difference between a commercial encoder and a free one.

[DSP8000]

64x64 is ok ? :> http://kurtnoise.free.fr/cr64.png Yes,tnx. I'll update the installer with the new icon.

DSP8000

[jruggle]

a possibility comes to mind (after reading DSP8000's comments about usability, lay users, etc):

- encoding and replaygain scanning can be done in 1 pass
- a very quick 2nd pass assigns dialnorm, mix level, and possibly DRC on the already encoded data using stats gathered from the 1st pass.

that way dialog normalization, mix level and DRC is always set properly without any need for the user to go find this information (which is often simply not available, even on the majority of DA-88 master tapes!)

just an idea... i'm hanging out for DRC mainly because, 5.1 coupling aside, it's the major difference between a commercial encoder and a free one.
That's a good idea. Although, I do want to be able to provide some streaming support with DRC as well (for S/PDIF). I could probably make the user specify the dialnorm setting if they want to encode with DRC in 1 pass.

What do you all think would be more useful to add first, a psychoacoustic model for better encoding quality, DRC, or channel coupling? Those are 3 big things on my list, and I can't quite make up my mind on where to focus my energy.

Also, is anyone using VBR mode? I may have to scrap it and redo it completely. When I alter the other bit allocation parameters to get better encoding, the quality measurement currently used is not consistant. Unless I can find another simple measure of quality I will either have to remove the VBR mode or wait until I get a psychoacoustic model working before tweaking the bit allocation params.

and...I finally purchased a DVD drive. :) So, now that I will have an endless supply of commercially-encoded sample files, I will probably add an AC3 frame analyzer to the Aften utils to be able to directly compare Aften-generated audio to commercially-generated audio.

-Justin

[raquete]

Also, is anyone using VBR mode?
few tests with VBR mode 200 only.the sound is kicking/popping in 2 standalones but perfect in pc.

[tebasuna51]

What do you all think would be more useful to add first, a psychoacoustic model for better encoding quality, DRC, or channel coupling? Those are 3 big things on my list, and I can't quite make up my mind on where to focus my energy.
Better quality (with psychoacoustic model and/or channel coupling) is always well valued, but can be superseded with high bitrates. DRC is a ac3 feature and any encoder without DRC is incomplete for me. My vote for DRC.
Also, is anyone using VBR mode?
To be honest ac3 is necessary for compatibility with DVD/DivX standalone players, AFAIK VBR is not compatible. Try to compete with aac, ogg, ... in PC players at this moment is a hard way.

[ADLANCAS]

Is there a feature missing in Aften to get full compatibility to DVD standalone players ?

- encoding and replaygain scanning can be done in 1 pass
- a very quick 2nd pass assigns dialnorm, mix level, and possibly DRC on the already encoded data using stats gathered from the 1st pass.
Good idea.

Ulead DVDWorkshop 2 creates an ac3 2.0 without parameter like Dialog Normalization. For sure, there is a kind of "auto normalization" in its code. It makes the things easier.:D Until now I´m satisfied with results.

[raquete]

@ Mug Funky
cool ideas.

i only don't understood:
- encoding and replaygain scanning can be done in 1 pass
replaygain can scan encoded 5.1?

thanks.

[jruggle]

@ Mug Funky
cool ideas.

i only don't understood:

replaygain can scan encoded 5.1?

thanks.
With stereo, replaygain uses the average (using log addition) of the left and right channels. I don't know if replaygain defines how to get a value for multi-channel audio, but there are probably several ways that 5.1 channels could be combined to give a good overall loudness measurement.


Ulead DVDWorkshop 2 creates an ac3 2.0 without parameter like Dialog Normalization. For sure, there is a kind of "auto normalization" in its code. It makes the things easier. Until now I´m satisfied with results.
A single ac3 "program" (tv show, movie, commercial) is supposed to have a constant dialnorm value, so unless DVDWorkshop does a 2-pass encoding behind-the-scenes it is probably just using a default value rather than trying to guess from the source audio.

[DSP8000]

I think approach like in besweet it is proven to work so why the need for a change?
BeLight & BeHappy are scanning the levels before encode, log the information then encode with the overal level adjustments.

Also, from developing side of view I vote for DRC, then psychoacoustic model, channel coupling, finally automated level adj/mix.
About psychoacoustic model, I'm a bit sceptic coz the overal sound will vary.

VBR for ac3? I think no.

Maybe it is better to make some presets for 2.0 & 5.1 but in advanced mode give the user full options.

Lame is very good on presets, the devs at HA have spend enormous effort on providing easy yet good/functional presets.

DSP8000

[Mug Funky]

my first though was psymodel should be first, but then people can spend years on that...

so my vote is DRC, then channel coupling (they come pretty close though).

but you're the developer - choose the one you're more interested in :)

btw, there's a couple of other ac3 things that currently aren't well supported in the "free world":

- timecode
- non-intel byte order

in fact, it's probably just those two. the thing is these types of ac3 never occur in DVD, so it's not often encountered. though it's not important to support these things... it's more something i wish decoders would handle (especially the byte order thing...grrr. have to import it into spruce, compile it, then rip it out of the compile just to be able to decode it).

keep up the good work :)

[jruggle]

my first though was psymodel should be first, but then people can spend years on that...
True. I am just starting to finally wrap my head around the concepts, but maybe I should just keep researching before jumping right into it.


so my vote is DRC, then channel coupling (they come pretty close though).

but you're the developer - choose the one you're more interested in :)

DRC is probably next feature I'll try to implement. Now that I have a basic filter basecode I can add the equal loudness filter. There is plenty of documentation as well. I just have to delve into it and organize all the info from various sources. Also, the concepts are much easier to understand for a beginner like myself than psychoacoustics.


btw, there's a couple of other ac3 things that currently aren't well supported in the "free world":

- timecode
- non-intel byte order

I never bothered with adding timecodes, but oddly enough I stumbled across the idea again today while reading through the Dolby encoding guidelines. I'm guessing DVD players just use the MPEG-PS timecodes and ignore the ones in the AC3 elementary stream. So would the AC3 timecodes only be useful for authoring programs?

As far as encoding in motorola byte order...I didn't know it was even supported. How does the decoder know?...reversed syncword? I vaguely recall that RealAudio 3 (DolbyNet) might use big-endian byte order...is that what you're referring to?

[Mug Funky]

timecodes get stripped out by the authoring program on compile, and non-intel byte order gets flipped around at the same time. that's why one doesn't encounter these streams often.

i only ever notice them when seeking an avs that's loading one - both nicac3source and bassaudiosource fail in the same way, and even playing out from the beginning seems oddly borked. the audio is good, just completely and unpredictably out of sync...

they're not at all useful though - and in fact if they're needed i can always steal them from another file (we've got a piece of software that just copies userdata from one ac3 to another).

As far as encoding in motorola byte order...I didn't know it was even supported. How does the decoder know?...reversed syncword? I vaguely recall that RealAudio 3 (DolbyNet) might use big-endian byte order...is that what you're referring to?
i really have no idea how it works... the only 2 programs i know that even handle it (on a PC) are DVDmaestro (i'm sure scenarist can too) and Soft Encode (which can decode it, but not transform it to intel order without recompression). i think they're produced by Mac DVD software.

[Gabriel_Bouvigne]

My vote if for a live DRC first.
It is quite an important part of AC-3. Some companies are selecting AC-3 over mpeg audio just for the dialog level field.

[Mug Funky]

hmm... it just occured to me (after looking through some encodes here that are clearly too quiet) that DRC and dialnorm could work quite well as separate processes - so we can scan an already encoded file and apply new DRC and dialnorm to it... sort of like mp3gain but more powerful.

...that may be outside the scope of aften, but it'd certainly be useful as hell.

[jruggle]

hmm... it just occured to me (after looking through some encodes here that are clearly too quiet) that DRC and dialnorm could work quite well as separate processes - so we can scan an already encoded file and apply new DRC and dialnorm to it... sort of like mp3gain but more powerful.

...that may be outside the scope of aften, but it'd certainly be useful as hell.
Good idea. The only impedement I see is that the ac3 data would need to be decoded in order to analyze it. Maybe I could try to do something which uses only the MDCT exponents to estimate loudness? I'll do some experimentation once I get the DRC working during encoding.

How does mp3gain work? Does it do a full decode of the mp3 in order to analyze it?

[raquete]

jruggle,
i'm right now reading about replaygain/mp3gain:

http://wiki.hydrogenaudio.org/index.php?title=Replaygain

http://en.wikipedia.org/wiki/Replay_Gain

regards.

[ursamtl]

I've been doing quite a bit of experimenting lately with Replaygain and I'm quite impressed with its potential. It will definitely play a part in the next version of my stereo-to-surround guides.

[jruggle]

How does mp3gain work? Does it do a full decode of the mp3 in order to analyze it?
I found the answer to my own question by looking at the source code for mp3gain. It does fully decode the mp3 to analyze it using a "light" version of the mpg123 decoder.

I really do not want to include a decoder with Aften, so either I will make an attempt to do a basic parsing to get exponents only or I might create a completely separate program which would use the liba52 decoder, analyze for dialnorm/DRC, then output modified ac3 frames.

[daphy]

btw, there's a couple of other ac3 things that currently aren't well supported in the "free world":

- timecode
- non-intel byte order

Hi folks,
I don´t know if this fitts to that context :o but I've found a thread (http://forum.gleitz.info/showthread.php?t=26858) on the German Doom9 concerning a patcher (including documentation in German and download (http://forum.gleitz.info/attachment.php?attachmentid=77208&d=1140388048)) which is able to patch little endian <-> big endian byte order without reencoding. The thread is in German but the patcher works as commandline tool using the following code:
ac3swap.exe SourceFile.ac3 < and > RETURN

[Mug Funky]

thanks for that daphy!

that'll save loads of time compiling and demuxing (which was the only way i could swap them before).

i'll have to do a few tests to ensure it gives binary-identical results to the spruce method, but i'm sure it's fine.

[Gabriel_Bouvigne]

I really do not want to include a decoder with Aften, so either I will make an attempt to do a basic parsing to get exponents only or I might create a completely separate program which would use the liba52 decoder, analyze for dialnorm/DRC, then output modified ac3 frames.
I think that it would be quite nice to be able to compute the "dialog level" directly during encoding. This would allow live encoding.
I think that it sould be possible to obtain a good approximation of dialog level using exponents values (weighted according to freq band)

[tebasuna51]

I think that it would be quite nice to be able to compute the "dialog level" directly during encoding. This would allow live encoding.
I don't agree with this comment and similar.
- This force to 2 pass encoding, and not live encoding.
- Automatic Dialog Normalization can work maybe with modern music, but never with movie tracks. The correct DialNorm must be calculated over a selected fragment with dialogs presents, not over the full track with aleatory silences.
- There are enough tools to calculate this parameter over the source to be encoded, and the related DRC type (film, music, speech, ...) I don't know how can be selected automatically.

[jruggle]

I think that it would be quite nice to be able to compute the "dialog level" directly during encoding. This would allow live encoding.
I think that it sould be possible to obtain a good approximation of dialog level using exponents values (weighted according to freq band)
The DRC can be done while encoding, but the dialog level is a trickier thing because it is supposed to be constant across the entire stream.

Like Tebasuna said, the dialog level should be measured using just an excerpt which typifies the dialog level of the whole stream. I can modify the wavrms utility program to accept a time or sample range and improve the dialnorm calculation as well...and/or include it in Aften as a 2-pass option.

A possible solution for live encoding might be to add some sort of "dialog calibration" functions in libaften. Something like start_calibration(), append_calibration(audio samples), end_calibration(). This could be used by a live encoder app to do a sort of microphone test. Or it could be used by a production app by passing a user-selected dialog range. Extending that idea to modifying existing AC3 streams, it could optionally take ac3 frames as input and analyze the exponents.

I'm just throwing ideas out here... I need to get the DRC actually working before jumping into any of these. :)

[Mug Funky]

with live stuff, the level should already be sorted before it hits the encoder

so i can't see it hurting to just enter a number in the CLI, then let the DRC handle the rest. if it's a little off it shouldn't hurt too bad. considering other encoders rely on user input, there's no reason aften can't too :)

perhaps a "-live" switch or similar could be added so aften knows how many passes to do? or perhaps 2-pass should be specified explicitly (that's probablythe way to do it).

[Gabriel_Bouvigne]

The DRC can be done while encoding, but the dialog level is a trickier thing because it is supposed to be constant across the entire stream.
...
I'm just throwing ideas out here... I need to get the DRC actually working before jumping into any of these. :)
sorry, I mixed both (and it's now more clear due to your comments), mainly because I am not fluent with the AC3 standard.

At the Paris AES convention, some people from Swedish TV explained (roughly) how they are proceding:
DRC is computed on the fly, while dialog level is selected based on the content type (a set of standard values for movies/news/sports/advertising/...).
If we assume that this represent a typical use case, then what is needed is dynamic DRC and ability to manually specify dialog level (even while encoding).

[jruggle]

sorry, I mixed both (and it's now more clear due to your comments), mainly because I am not fluent with the AC3 standard.

At the Paris AES convention, some people from Swedish TV explained (roughly) how they are proceding:
DRC is computed on the fly, while dialog level is selected based on the content type (a set of standard values for movies/news/sports/advertising/...).
If we assume that this represent a typical use case, then what is needed is dynamic DRC and ability to manually specify dialog level (even while encoding).
That's a good point. There are probably many values (mostly metadata) that it might be good to read from the user context when encoding each frame instead of just at start of encoding. That way the user can change them during encoding without having to reinitialize.

[mean]

Hello,
Could you rename the private field of aftencontext to something else ?
It is c++ unfriendly :)

Thank you

[jruggle]

Hello,
Could you rename the private field of aftencontext to something else ?
It is c++ unfriendly :)

Thank you
Thanks for the info. I just changed it in SVN.

[ADLANCAS]

I´ve made a small batch file that uses the aplication wavrms.exe presents on Aften v0.05 package.

With this batch we can use Aften with a "automatic measure of parameter Dialog Normalization".

rem This batch works on Win-XP
@echo off
setlocal enabledelayedexpansion
wavrms.exe video1.wav | find "Dialnorm" > "Dialnorm.txt"

for %%F in (Dialnorm.txt) do (
for /F "usebackq tokens=1 delims=B" %%J in ("%%F") do (
set char=%%J
set char=!char:~12,2!
echo Dialnorm = - !char! dB
aften -b 224 -dnorm !char! -acmod 2 -bwfilter 1 -dcfilter 1 video1.wav video1.ac3
)
)

I hope that can be useful for community.:D

[raquete]

hi ADLANCAS
"automatic measure of parameter Dialog Normalization".
...rem This batch works on Win-XPi'm horrible in command lines and need to ask you if works in 2K too.

:thanks: so much.

ps:
are you from SP,MG,RJ,CE,RS...? (BR here too)

regards.

[ADLANCAS]

i'm horrible in command lines
Me too:)

It should also run in 2K.

(Here is SP)

[Chainmax]

What is currently being worked on?

[jruggle]

What is currently being worked on?
DRC, dialnorm, and speed. Also, I'm trying to make up my mind on changing the build system.

I just applied a simplification of the dialnorm calculation in wavrms. Instead of using the sort/percentile approach as in replaygain, I chose something a bit simpler. Now it does averaging of RMS, but throws out values which are outside of a reasonable dialog range. Some testing has shown that it works pretty well. I'd really like to get some feedback on it though. Since it was applied today, it will show up in tomorrow's daily build.

-Justin

[ADLANCAS]

You could see his blog:
http://aftenblog.blogspot.com/

[Chainmax]

Oh, I forgot about the blog :o. Justin, do you think channel coupling might be a possibility in the future?

[raquete]

@ jruggle,

I just applied a simplification of the dialnorm calculation in wavrms.
i can't wait to use, just waiting for Kurt new Gui with that feature. :cool:
Instead of using the sort/percentile approach as in replaygain, I chose something a bit simpler.
jruggle,you left the idea to use replaygain in Aften?

thanks.

[NorthPole]

Inline resampling is on my TODO list. Also, optionally downmixing or upmixing the number of channels is on the TODO list. :) The list just keeps growing!

-Justin

@justin
I know you probably have a long TODO list but... Any chance that you have made any progress on inline resampling? Like from 44100 to 48000.

[Exl]

Aften is looking great so far, but I have a file on which it generates bad output. The wav source is this 20 second excerpt:
http://members.home.nl/meuwissenth/0.0.0.wav
Which sounds just fine. Once I run it through Aften with the parameters -b 192 -acmod 2 or even just either one of them, it outputs this:
http://members.home.nl/meuwissenth/0.0.0.ac3
Which plays back with pauses and the seeker bar visibly skipping in VLC Media Player. Am I doing something wrong here?

[tebasuna51]

Which plays back with pauses and the seeker bar visibly skipping in VLC Media Player. Am I doing something wrong here?
Seems only VLC are doing something wrong, because Winamp, Foobar, Bsplayer and PowerDVD play correctly the file.
Azid and the new NicAudio (is a 44100 Hz) can decode the 0.0.0.ac3 without problems.

The same wav resampled to 48000 play ok with VLC, and other ac3 44100 Hz have the same problem in VLC.

Edit: my vlc version is 0.8.2

[jruggle]

jruggle,you left the idea to use replaygain in Aften?

Yes, sort of. The basic RMS calculation is still there. Replaygain does not have anything to do with dialog level though, it has to do with _overall_ perceived loudness. The 95% point does a good job for that measurement, but for dialog in a movie, for example, it isn't as good. I was adjusting it down by a fixed amount as an educated guess based on sample data...this really was not very accurate though. The new method throws out very quiet and very loud sections, which can occur pretty often in movies, but rarely include normal dialog. Also, the specification of a time range gives the user more control to select a good section of audio which has typical dialog.

[danpos]

@ALL

I'm coming back to use Linux (Ubuntu) and so I did solve to download the aften-daily-091906.tar.bz2, compiled it and did a Debian Package (Ubuntu) for easily install/uninstall/upgrade it. Just in case anyone is interested, here is it:aften_09192006-SVN-1_i386.deb (http://www.megaupload.com/pt/?d=ZXP88FV0).

Regards,

[Exl]

Seems only VLC are doing something wrong, because Winamp, Foobar, Bsplayer and PowerDVD play correctly the file.
Azid and the new NicAudio (is a 44100 Hz) can decode the 0.0.0.ac3 without problems.

The same wav resampled to 48000 play ok with VLC, and other ac3 44100 Hz have the same problem in VLC.

Edit: my vlc version is 0.8.2

Yep you're right, anything other than VLC plays it back fine. But there is still one problem; after I've encoded the wav file, I multiplex the resulting ac3 with an MPEG2 video stream using mplex. It has a few complaints about the source, namely


++ WARN: [???] Stream e0: data will arrive too late sent(SCR)=1403465 required(DTS)=0
++ WARN: [???] Video e0: buf= 158603 frame=000463 sector=00004583
++ WARN: [???] Audio bd: buf= 5673 frame=000455 sector=00000189
++ WARN: [???] Stream e0: data will arrive too late sent(SCR)=4493604 required(DTS)=0
++ WARN: [???] Video e0: buf= 158603 frame=001492 sector=00020338
++ WARN: [???] Audio bd: buf= 5345 frame=001442 sector=00000598
++ WARN: [???] Discarding incomplete final frame AC3 stream 0!


Later on in the process I let DVDAuthor loose on the resulting mpeg file to turn it into a DVD, and it complains even more about the audio stream;


WARN: Unknown AC3 sample rate: 1
WARN: Unknown AC3 sample rate: 1
WARN: Discontinuity in audio channel 0; please remultiplex input.
WARN: Previous sector: 0.178 - 0.274
WARN: Current sector: 0.282 - 0.346
WARN: Unknown AC3 sample rate: 1
WARN: Discontinuity in audio channel 0; please remultiplex input.
...


That's the only thing that bugs me. I have not tried out the resulting DVD on a stand-alone DVD player yet, but no other audio tracks that I've tested with show this odd stuttering.

[NorthPole]

Had a question about the bandwidth settings

I have been using -w 50 -bwfilter 1 which I believe results in a high bandwidth cut-out at 20kHz.

I was wondering if anybody knows if that is correct and at what point does the low pass bandwidth filter apply?

Maybe I am not understanding this correctly, but if the bandwidth is already limited at 20kHz, what would you need the DC high pass filter for?

[tebasuna51]

Later on in the process I let DVDAuthor loose on the resulting mpeg file to turn it into a DVD, and it complains even more about the audio stream;
AFAIK, you need always a 48000 Hz ac3 for use in DVD.

You need resample the original wav to 48000 and after encode with aften.

[Exl]

Thanks, that did indeed solve the problem. VLC plays the ac3 file fine too now. It also means I'm going to use Aften in my DVD authoring app isntead of BeSweet now :) BewSweet isn't maintained anymore and has some weird unexplainable bugs when handling WAV files. http://dvdflick.sourceforge.net/ if you're interested.

[jruggle]

Had a question about the bandwidth settings

I have been using -w 50 -bwfilter 1 which I believe results in a high bandwidth cut-out at 20kHz.

I was wondering if anybody knows if that is correct and at what point does the low pass bandwidth filter apply?

Maybe I am not understanding this correctly, but if the bandwidth is already limited at 20kHz, what would you need the DC high pass filter for?

The formula, for a given samplerate, is ((w * 3) + 73) / 512 * samplerate)
For 48kHz audio, -w 50 gives a cutoff of 20.9 kHz.

The bandwidth low-pass filter is centered on the cutoff frequency point and is meant to give a smoother transition at the cutoff point.

The DC high pass filter is at the other end of the spectrum. It has a cutoff at 3 Hz. This removes any DC offset that may be present in the signal.

Hope this helps,
-Justin

[NorthPole]

The bandwidth low-pass filter is centered on the cutoff frequency point and is meant to give a smoother transition at the cutoff point.

Yes this was very helpful. What is the cutoff point?


The DC high pass filter is at the other end of the spectrum. It has a cutoff at 3 Hz. This removes any DC offset that may be present in the signal.


So does this mean that this can correct DC offset up to 3HZ at whatever your high side cutout is (such as 20kHz when using -w 50)?
Thanks

[raquete]

NorthPole,
from sonic foundry soft encode help:

"DC high-pass filter
This parameter will apply a DC High-pass filter to the encoded stream when checked. This filter is used to remove any DC offset that is present in the source audio files. It is recommended that this option be checked for best results."

[Gabriel_Bouvigne]

In frequency based coding, the DC offset is not that a big deal.
Usually it's only affecting 1 single coefficient, so removing it will not change much regarding encoder's quality.

[NorthPole]

@raquete and @Gabriel

Thanks for the info.

[vmesquita]

I have updated my hack to allow 6 wav BeSweet-style input. In case anyone is interested, download the exe here:
http://www.vmesquita.com/files/aften005-6wav.zip
Source patch can be downloaded here (patch only aften.c):
http://www.vmesquita.com/files/patch_aften.zip

Support for aften will be added in the next DIKO release :D

[danpos]

@vmesquita

Great news, V! :D

Kept up! ;)

See ya,

[jruggle]

I have updated my hack to allow 6 wav BeSweet-style input. In case anyone is interested, download the exe here:
http://www.vmesquita.com/files/aften005-6wav.zip
Source patch can be downloaded here (patch only aften.c):
http://www.vmesquita.com/files/patch_aften.zip

Support for aften will be added in the next DIKO release :D

Hmm. I like the idea. I might add this feature as a commandline option. I have a question though, are those filenames for each wav something that is fixed and defined? From the code it looks that way, but I don't know a lot about BeSweet.

Thanks,
Justin

[vmesquita]

Hi jruggle,

Yes, I coded it to use a fixed name. So if you specify the input file as "audio", first aften will look for a file named "audio". If it doesn't find, it will look for the six wavs, which would be:
audio-C.wav
audio-SL.wav
audio-SR.wav
audio-FR.wav
audio-FL.wav
audio-LFE.wav
If all this files exist, aften will encode then togheter. If one of then if missig it will abort. I found it easier to implement this way, putting each file in the command-line would be a lot of work. :) But feel free to improve it if you decide to add to official releases, I didn't elaborate too much on this.

[jruggle]

Hi jruggle,

Yes, I coded it to use a fixed name. So if you specify the input file as "audio", first aften will look for a file named "audio". If it doesn't find, it will look for the six wavs, which would be:
audio-C.wav
audio-SL.wav
audio-SR.wav
audio-FR.wav
audio-FL.wav
audio-LFE.wav
If all this files exist, aften will encode then togheter. If one of then if missig it will abort. I found it easier to implement this way, putting each file in the command-line would be a lot of work. :) But feel free to improve it if you decide to add to official releases, I didn't elaborate too much on this.
Cool. That gives me an idea of how to implement it. I think I'll do something like "aften -multiwav 1 audio-*.wav audio.ac3". That way the user could set whatever naming scheme they want, but the * would be replaced with C/SL/SR/FR/FL/LFE. For example, the user could do something like "my_dvd-*_channel.wav". Also, I think I could make it work with other channel layouts if the user specifies the acmod. Before I jump right into it, does this sound like a good usable solution?

-Justin

[canuckerfan]

Good encoder. Thanks for all the work :)

Quick Q, will VBR AC3 play in the vast majority of DVD players? I'm guessing not...

[chickenmonger]

Support for aften will be added in the next DIKO release :D

I've always had a hard time deciding between AVI2DVD, TheFilmMachine, and DIKO for each AVI to DVD transfer I do, and this may tip the scales heavily in DIKO's direction.

Right now I usually have to let the programs encode to MP2, decode to WAV, and use Aften to encode to AC3, all to avoid the volume bug in BeSweet's ac3enc.dll.

[vmesquita]

Cool. That gives me an idea of how to implement it. I think I'll do something like "aften -multiwav 1 audio-*.wav audio.ac3". That way the user could set whatever naming scheme they want, but the * would be replaced with C/SL/SR/FR/FL/LFE. For example, the user could do something like "my_dvd-*_channel.wav". Also, I think I could make it work with other channel layouts if the user specifies the acmod. Before I jump right into it, does this sound like a good usable solution?

Hi Justin,

Yes, it's perfectly usable, not to mention it's a much more generic solution. :D

Right now I usually have to let the programs encode to MP2, decode to WAV, and use Aften to encode to AC3, all to avoid the volume bug in BeSweet's ac3enc.dll.
ac3enc has this bug and some incompatibilities with some SAPs, that's why I never added support for it in DIKO. Now aften will definatelly be the best solution for this dilemma. :D

[Kurtnoise]

Before I jump right into it, does this sound like a good usable solution?
Why not create a switch to allow loading text file which included each filenames ?

[TFM_TheMask]

I've always had a hard time deciding between AVI2DVD, TheFilmMachine, and DIKO for each AVI to DVD transfer I do, and this may tip the scales heavily in DIKO's direction.

Right now I usually have to let the programs encode to MP2, decode to WAV, and use Aften to encode to AC3, all to avoid the volume bug in BeSweet's ac3enc.dll.

Why is that so. Aften is already implemented in the latest release of The FilmMachine which was released yesterday.

[jruggle]

Why not create a switch to allow loading text file which included each filenames ?
Yeah, that might be a better option. I just noticed that in bash (a common unix shell) doing *.ac3 sometimes feeds the files in reverse alphabetical order? I don't know if this same thing holds true for Windows' command shell or Unix shells other than bash, but at any rate, it could get tricky.

In order to not confuse the channel order issue, my first thought as to a text file format is this:

# any 1-line comment
L=audio-left.wav
R=audio-right.wav
LFE=audio-lfe.wav
C=audio-center.wav
S=audio-surround.wav
SL=audio-surleft.wav
SR=audio-surright.wav

This would support specifying the channels in any order and would allow for channel modes other than 5.1.

comments/suggestions?

-Justin

[chickenmonger]

Why is that so. Aften is already implemented in the latest release of The FilmMachine which was released yesterday.

I had not checked prior to my post; that's exciting news. Times like these are why I love free software. You get to choose the best tool for the job and it doesn't cost anything more.

Thanks, everyone.

[tebasuna51]

Yeah, that might be a better option.
...
This would support specifying the channels in any order and would allow for channel modes other than 5.1.

comments/suggestions?
I think is more easy instruct the users to put exact suffix in filenames than create a text file with a especific syntax.

With:
Aften -b 256 -acmod 5 -prefix path\audio.wav audio.ac3

must exist in path\:
audioL.wav
audioC.wav
audioR.wav
audioS.wav

And with:
Aften -b 448 -acmod 7 -lfe 1 -prefix path\audio.wav audio.ac3

must exist in path\:
audioL.wav
audioC.wav
audioR.wav
audioSL.wav
audioSR.wav
audioLFE.wav

If the text file is the final method, at least use the BeSweet format well know for many users:
Aften -b 448 -acmod 7 -lfe 1 -mux audio.mux audio.ac3

Where audio.mux is:
path\audio_FL.wav
path\audio_FR.wav
path\audio_FC.wav
path\audio_LFE.wav
path\audio_BL.wav
path\audio_BR.wav
with the order like wav channels order.

[vmesquita]

I completelly agree with tebasuna51, except that I prefer the audio*.wav idea (i.e. using wildcards)

[jruggle]

If the text file is the final method, at least use the BeSweet format well know for many users:
Aften -b 448 -acmod 7 -lfe 1 -mux audio.mux audio.ac3

Where audio.mux is:
path\audio_FL.wav
path\audio_FR.wav
path\audio_FC.wav
path\audio_LFE.wav
path\audio_BL.wav
path\audio_BR.wav
with the order like wav channels order.
I didn't know there was a standard already. Perhaps I'll make it compatible with the BeSweet way, but add the option to do it my suggested way as well.

First of all, allowing comments doesn't break compatibility. Also, if the user decides to use "L=", "R=", etc... then the file order won't matter, but if the user does it the BeSweet way then the files must be in the correct order.
Does that sound workable?

I guess I could do both. I could change it to require "-o output.ac3" and allow multiple input files. If the -mux option is used, the input files would need to have the R,L,C,SR, etc... post-fixes. A file could be specified with "-muxfile channels.mux".

This way would also support encoding multiple files in a row if the -mux option is not used. It would allow for using wildcards or multiple full filenames.

examples:

muxing using text file:
aften -muxfile channels.mux -o audio-6ch.ac3

muxing using individual files and wildcards:
aften -mux audio-*.wav -o audio-6ch.ac3

muxing using individual filenames (using weird prefixes to show why someone might want to do this):
aften -mux aud-lt.wav aud-rt.wav aud-c.wav aud-lfe.wav aud-surl.wav aud-surr.wav -o audio-6ch.ac3

encoding multiple files sequentially, replacing each ".wav" with ".ac3":
aften *.wav

(maybe...) encoding multiple files sequentially, splicing them together into 1 file:
aften *.wav -o joined.ac3


Does this way sound better?

-Justin

[Kurtnoise]

sounds good to me...:)

[tebasuna51]

...
Does this way sound better?
If you accept, and implement, all the options, everybody happy :)

But, warning :D , one more suggestion:
Accept stereo wav files for acmod 5,6,7.
With your sintax maybe LR=, CS=, CLFE=, SLSR=.

To justify this:
- Is a common task modify a multichannel source in stereo wav editors, and front/surround channels have common procedures.
- In GUIDE: Converting stereo to 5.1 surround for FREE (http://forum.doom9.org/showthread.php?t=105684) the last step is encode three stereo wav's fLfR, CLFE, slsr.

[NorthPole]

@jruggle

Just as another option (or example), you could do it like soft encode with the following command line where test.ini is the encoder settings:

the input is in1.wav thru in6.wav for 6 individual wave files

SFTENCDD.exe -A -P test.ini -o out.ac3 -L in1.wav -R in2.wav -C in3.wav -e in4.wav -l in5.wav -r in6.wav

or for 3 wave files

SFTENCDD.exe -A -P test.ini -o out.ac3 -L in1.wav -R in1.wav -C in2.wav -e in2.wav -l in3.wav -r in3.wav -0L in1 -1R in1 -0C in2 -1e in2 -0l in3 -1r in3

or for 1 wave file

SFTENCDD.exe -A -P test.ini -o out.ac3 -L in1.wav -R in1.wav -C in1.wav -e in1.wav -l in1.wav -r in1.wav -0L in1 -1R in1 -2C in1 -3e in1 -4l in1 -5r in1

obviously not the nices command line to work with but maybe a hybrid could be used.

[jruggle]

If you accept, and implement, all the options, everybody happy :)
Great. I am currently working on a multiple-file framework for both my ac3 and flac encoders, so it shouldn't be too long. (not as long as it's taking me to get DRC implemented ;))


But, warning :D , one more suggestion:
Accept stereo wav files for acmod 5,6,7.
With your sintax maybe LR=, CS=, CLFE=, SLSR=.

Good point. I'll add that to the design. Would any other channel combos be warranted or are those 4 pretty standard?

[Mug Funky]

you could always make your own 6ch-in-stereo format...

or maybe use string searches and have underscores as delimiters - like "file_LFE_C.wav", or "file_FL_SL.wav", etc.

but that'll be a distraction from the more important stuff. there's no shame in supporting whatever naming strategy you prefer and having users conform to that - it's a command line encoder after all, so people will have to learn aften's particular style of command syntax anyway.

whichever way it's done, it can't possibly be as annoying as Soft Encode's CLI syntax (no quotes allowed? wth?).

[Rockaria]

Good points everybody. It seems being developped into a most important part of the encoder.

I also have an idea : a context driven approach

By any suffix naming convention in the source path :
i.e. audio_L.wav, audio_R.wav, audio_LR.wav, audio_LR_SLSR.wav...
or audio.mux, audio.wav(these may require the explicit -acmod)

by the shell command 'dir path/audio*.*', it will be eventually parsed into each channels and even can define the -acmod.

[-acmod #] Audio coding mode (overrides wav header)
0 = 1+1 (Ch1,Ch2)
1 = 1/0 (C)
2 = 2/0 (L,R)
3 = 3/0 (L,R,C)
4 = 2/1 (L,R,S)
5 = 3/1 (L,R,C,S)
6 = 2/2 (L,R,SL,SR)
7 = 3/2 (L,R,C,SL,SR)

A table of the supported tool's context naming convention must be established.
Any future format channels can also be supported this way : extensible.

[BabaG]

just downloaded aften and looks very nice. noob question.
seems to be a lot of discussion here of multi-wav encoding
so i'm not sure if aften will yet do what i'm trying to do. i
have six mono wav's - l,c,r,ls,rs,lfe. i want to use them as
a soundtrack on a dvd i want to author. i gather i need to
encode them somehow. will aften do this? what is the
command?

this, then, produces an ac3 file? is that compatible with the
authoring process? or is it an intermediate on the way to an
mpeg of some sort?

sorry for the dumb questions but these are rather deep
waters for the novice swimmer. finding aften seems to
provide some real encouragement for me.

thanks,
BabaG

[raquete]

ah...hi!
the first post is one good starting point (always).

http://forum.doom9.org/showthread.php?t=113074

have a cool GUI for newbys(like me)and "lazy" people.

[tebasuna51]

i have six mono wav's - l,c,r,ls,rs,lfe. i want to use them as a soundtrack on a dvd i want to author. i gather i need to encode them somehow. will aften do this? what is the command?

this, then, produces an ac3 file? is that compatible with the authoring process? or is it an intermediate on the way to an mpeg of some sort?
You can try the vmesquita version (http://forum.doom9.org/showthread.php?p=881196#post881196) or make a wav 6 channels (the order is l,r,c,lfe,sl,sr) with WaveWizard (http://www.rarewares.org/wavewiz/wavewizardv0.54b.zip) and use the standard Aften (don't support yet 6 monowav like input)

And, yes, produce an ac3 file compatible with the authoring process.

[BabaG]

there is an option in aftengui (i'm not in front of it right now) in the
preferences which has to do with dolby. i think there are three
options, something like none, disabled, enabled. what is this
for and what does it do exactly? about to get to my first serious
test with this. and thanks tebasuna51. very helpful.

thanks,
BabaG

[tebasuna51]

there is an option in aftengui (i'm not in front of it right now) in the
preferences which has to do with dolby. i think there are three
options, something like none, disabled, enabled. what is this
for and what does it do exactly?
Maybe:
[-dsur #] Dolby Surround mode
0 = not indicated (default)
1 = not Dolby surround encoded
2 = Dolby surround encoded
This flag is present only in ac3 2.0, and indicate when the two physical channels are encoded to contain 4/5 logical channels (Dolby ProLogic I/II).

Some players can use this info to activate automatically your DPL decoder.

The ac3 encoder (Aften) don't make the downmix dpl 5.1 -> 2.

[BabaG]

so, i started with six mono wav's of original material. i then
used wavwizard to create a single wav file with six channels.
how do i get this to be usable and playable as surround
sound on a normal dvd player? do i need to now convert the
six channel wav to two channels with some sort of encoding?
or can i just burn the aftengui ac3 of this six channel wav
along with my mpeg picture file using something like dvdstyler
and have it properly readable as a surround dvd? if it's
necessary to encode the six channel wav down to two,
software recommendation, please?

thanks again,
BabaG

[tebasuna51]

do i need to now convert the
six channel wav to two channels with some sort of encoding?
Not at all, is only a option for less quality/bitrate.
or can i just burn the aftengui ac3 of this six channel wav along with my mpeg picture file using something like dvdstyler and have it properly readable as a surround dvd?
Yes, I don't know dvdstyler, but any authoring software can do the job.

[chickenmonger]

I had an idea for a front-end for Aften, but the only programming languages I know (oddly enough) are BASIC and FORTRAN. Neither of those seem to be good languages for programming a front-end for anything.

I noticed a lot of programs offer Sonic Foundary's Soft Encode as an option for encoding AC3 audio. Could a front-end be coded that would take the command-line options and the generated INI file for Soft Encode and feed the relevant information to Aften? I tried to make such a front-end in QBASIC of all things last night, but I got stuck parsing the INI file.

I'll try again tonight, but I can't make any promises.

[Chainmax]

...
- In GUIDE: Converting stereo to 5.1 surround for FREE (http://forum.doom9.org/showthread.php?t=105684) the last step is encode three stereo wav's fLfR, CLFE, slsr.

Yes, but once those three files are created you can split them to 5 mono WAVs or a single 5.1 one.

Does Aften support encoding from a 5.1 WAV? Also, has channel coupling been scratched from the to-do list or could there be a possibility to resume work on it sometime in the future?

[raquete]

Does Aften support encoding from a 5.1 WAV?
yes and with AftenGUI is easy!

[BabaG]

i'm unclear on one thing here, the distinction between six channels
and surround, if there is one. i created six mono files as a surround
mix in an audio app. from that i created a six channel wav in
wavewizard. i then used aftengui to create an ac3. i'm about to try
burning that to dvd but would like to understand one thing: will this
ac3 be played as a surround track, or is it simply a stereo track with
alternate stereo pairs? i think of things like director commentary track
and various dvd extras and find myself wondering if my six tracks
will be played all together or will be played two at a time with my
having to select which pair to listen to. thanks for all the help so far.
with your help i feel like i'm gradually coming round to this technology.

[jruggle]

Also, has channel coupling been scratched from the to-do list or could there be a possibility to resume work on it sometime in the future?
Yes, channel coupling is still on the todo list (http://svn.sourceforge.net/viewvc/*checkout*/aften/Changelog?revision=101).

[Archimedes]

I have used BeSweet ("AC3Enc") long time to produce AC3 (DD 2.0) with a constant bitrate of 256 kbps for DVD authoring without any problems. RMAA (RightMark Audio Analyzer) tells me, that Aften would be the better solution. But can i trust only numbers? ;-) However, Aften seems to be a good replacement for the BeSweet solution. Isn’t it?

[raquete]

tells me, that Aften would be the better solution. But can i trust only numbers?;-) However, Aften seems to be a good replacement for the BeSweet solution. Isn’t it?
who knows?
as faith is personal i (maybe we) can't explain, read the link and taste the true:
http://aftenblog.blogspot.com/

regards.

[Mug Funky]

@ Archimedes:

have you tried it on motion-menus and played it on (old-ish) pioneer DVD players? that issue's the only thing holding me back from using ac3enc based stuff, and it was probably fixed ages ago but i'm too lazy to test :)

[Archimedes]

Never tried it on motion menus. I used it for authoring my own dv stuff. Never heard, that something is wrong with this DVDs. For a long time i read an article where some people (people who knows something about acoustic) did make a listening test. No one was able to hear the difference between BeSweet and Sonic Foundry Soft Encoder at 256 kbps.

Regarding Aften, i have another question. What is the correct way to convert a normal stereo wav (48 kHz, 16-bit, dv stuff) to AC3 (DD 2.0) at 256 kbps?

Is "aften input.wav output.ac3 -b 256" correct?

What about the -m parameter?

[-m #] Stereo rematrixing
0 = independent L+R channels
1 = mid/side rematrixing (default)

[tebasuna51]

No one was able to hear the difference between BeSweet and Sonic Foundry Soft Encoder at 256 kbps.
The same input.wav encoded with ac3enc-BeSweet is 50% (-3 dB) in volume than encoded with Sonic Foundry SoftEncode.
Last ffmpeg versions and Aften resolve this problem.

[Archimedes]

That’s another issue. I never unterstand this “volume bug”. When i hear my own DVDs the volume level seems to be the same as there will be used on most commercial DVDs.

[newhaven]

hi,

can anyone tell me what settings in the aften gui need to be checked for 5.1 ac3? i understand some of the obvious ones, but realize there is probably more. i have also looked for a guide on aften and have had no succuess.

thanx--newhaven

[jruggle]

Hi,
I just want to mention that my attempt at DRC encoding has been committed to Aften SVN. If anyone wants to try it out, the commandline option is -dynrng. Below is a snippet from the usage text.

[-dynrng #] Dynamic Range Compression profile
0 = Film Standard
1 = Film Light
2 = Music Standard
3 = Music Light
4 = Speech
5 = None (default)

-Justin

[Mug Funky]

unfortunately i'm not set up to compile anything, but i'm totally up for testing it!

i could probably compare results with results from soft encode and an MPX-3000 hardware encoder.

[Kurtnoise]

http://kurtnoise.free.fr/index.php?dir=Aften/&file=Aften-0.05_rev185.zip

10x Justin for drc...:)

[Mug Funky]

thanks both of you :) testing now.

[edit]

attack and release seem to be 1 ac3 frame...

i've attached 3 pics to demonstrate. i made a very simple test signal (10 seconds, silence, then 1k -20dB tone, then 1k -1dB tone, then back to -20dB for the rest), and encoded it in both soft encode and aften with "film standard" selected.

dialnorm for both encoders was -27dB, as this is the default round my parts (i think it corresponds well to the old -20dBFS = 0 dB VU rule).

soft encode's release time is extremely long (note: too long, it can sound really bad when an actor hits a hard "s" and the music drops out almost completely), but aften's attack and release seem to be extremely short. also doesn't seem to attenuate enough.

it did sound alright though on film content (Godzilla vs Spacegodzilla :))- sort of like a peak limiter :)

note i used foobar2000 with DRC enabled for decoding. though one thing i've noticed is different decoders can make a bit of a difference.

[edit 2]

i've managed to approximate soft encode's DRC using Audition's compressor. the values are a little odd, but it produces a similar shaped curve (it peaks higher, but i put that down to ac3's DRC working per-block rather than per-sample).

settings are:

4:1 compress above -20dB, unity gain below.
attack time 200ms, release time 20,000ms (!!)

personally i think 20 seconds is far too long - i can't see a soundtrack suffering if the release is 5 sec or even 1 sec.

[jruggle]

attack and release seem to be 1 ac3 frame...

I didn't even think of that. The Dolby guidelines don't mention attack and release. It's actually 1 block, not 1 frame, since the dynrng value is computed for each block. This definitely explains the odd results I'm getting sometimes. What would you recommend to be good attack/release times?

-Justin

[tebasuna51]

Other test similar to Mug Funky (I can't see the images yet):

Ten seconds of 1 KHz tone with -45, -40, ..., -5, 0 dB.
Encoded with SoftEncode and Aften, Film Standard, -31 dB DialNorm.
Decoded with Azid 1.9 ( -d normal ).

http://img303.imageshack.us/img303/9172/aftendrc31cq6.png (http://imageshack.us)

Seems we need more attenuation for high values.
There are the theoretic Dolby curves and attack/decay parameters in Apendix C of “Dolby Laboratories Digital Professional Encoder Manual" (http://www.dolby.com/tech/L.mn.0002.DDPEG1.pdf)

[jruggle]

Seems we need more attenuation for high values.
There are the theoretic Dolby curves and attack/decay parameters in Apendix C of “Dolby Laboratories Digital Professional Encoder Manual" (http://www.dolby.com/tech/L.mn.0002.DDPEG1.pdf)
Thanks for that. Now I'm a little confused though. Dolby's metadata guidelines give both "early cut" and "cut" ranges and ratios, but the professional encoder manual leaves out "early cut" altogether. Also, I think I may be interpreting something incorrectly. I might need a little help here.

Let's take Film Standard, for instance.
max boost 6 dB
(abs range) (-43 dBFS)
boost ratio 2:1
(abs range) (-43 to -31)
null band width 10 dB
(abs range) (-31 to -21)
cut ratio 20:1
(abs range) (-21 to +4)
max cut 24 dB
(abs range) (+4 dBFS)

This is my interpretation. A signal which has loudness below -31 gets a boost of 0.5 dB for every loudness dB below -31, giving a maximum 6 dB boost at -43. For a signal which has loudness above -21, this is where I get lost. I interpret the 20:1 ratio to mean that each dB above -21 only adds 0.05 dB of cut. Not only does this not make sense, but it doesn't add up to the max cut of 24 dB. It would have to be 1 dB of cut for each 1 dB increase in loudness for it to add up right. Am I missing something here?

-Justin

[tebasuna51]

A signal which has loudness below -31 gets a boost of 0.5 dB for every loudness dB below -31, giving a maximum 6 dB boost at -43. For a signal which has loudness above -21, this is where I get lost. I interpret the 20:1 ratio to mean that each dB above -21 only adds 0.05 dB of cut.
Yes, there are other documents with one more segment ("early cut") and you can see also this image. (http://pages.sbcglobal.net/wilsondr/ddcompprof.gif)
But always Film Standard are below -20 dB like SoftEncode make.
Not only does this not make sense, but it doesn't add up to the max cut of 24 dB. It would have to be 1 dB of cut for each 1 dB increase in loudness for it to add up right. Am I missing something here?
The input range -21 dB to 0 dB have the output range -21 dB to -19.95 dB.
Really is not clear this max cut of 24 dB. The second Note to Table C-1 say:
"Some absolute ranges extend higher than 0 dBFS. Since a full-scale sine wave cannot exceed 0 dBFS, these ranges should be interpreted as extrapolated extensions of the allowable range. As a result, it may not be posssible in practice to achieve the maximum cut compressions gain words."

Thanks for your job.

[jruggle]

Yes, there are other documents with one more segment ("early cut") and you can see also this image. (http://pages.sbcglobal.net/wilsondr/ddcompprof.gif)
But always Film Standard are below -20 dB like SoftEncode make.

The input range -21 dB to 0 dB have the output range -21 dB to -19.95 dB.

Makes much more sense now. Thanks tebasuna! I'll try to adjust the calculations accordingly. It may take some more time to get the attack/decay thing working though.

edit: 1st, the aften -h output was mixed up. It is now corrected. 2nd, I think DRC calculation should be more correct now (although the "standard" profiles still give noisy output due to the changes being too abrupt...i.e. no attack/decay implemented).

-Justin

[Mug Funky]

i vote for CLI options for attack/release/etc :)

default can be the dolby one once it's figured out (the terminology is slightly different to what you'd get on a regular compressor/expander)

thanks heaps for the good work!

[tebasuna51]

I can't access sources or others revisions, http://jbr.homelinux.org/aften/ don't work for me and http://sourceforge.net/projects/aften is outdated.
Then only can test Kurtnoise13 binarys. The last is Aften rev 205 (Aften205).

To compare I have only Sonic Foundry SoftEncoder (SoftEnc.)

And the theoretic curves can be from two Dolby documents:
The 4 segment curve from Dolby Digital Professional Encoding Guidelines (http://www.dolby.com/tech/L.mn.0002.DDPEG1.pdf) (Teoric4s)
And the 5 segment curve ("Early Cut" added, not for Music Light) from Dolby Metadata Guide (http://www.dolbylabs.com/assets/pdf/tech_library/18_Metadata.Guide.pdf) (Teoric5s)

With all values in -dB and
FL = Film Light
FS = Film Standard
ML = Music Light
MS = Music Standard
SP = Speech

-dB Wav DRC 45 40 35 30 25 20 15 10 5 0
-------- --- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Teoric5s FL 43 40 35 30 25 20.5 18 15.9 15.7 15.4
Teoric4s FL 43 40 35 30 25 20.9 20.7 20.5 20.2 19.9
SoftEnc. FL 44.0 40 35 30 25 21.0 20.8 20.6 20.3 20.0
Aften205 FL 41.5 39.0 35 30 25 20.0 16.5 14.1 12.8 12.6

Teoric5s FS 39 35.5 33 30 25.5 23 20.9 20.5 20.2 19.9
Teoric4s FS 39 35.5 33 30 25 20.9 20.7 20.5 20.2 19.9
SoftEnc. FS 44.0 37.8 33.1 30 25 21.0 20.8 20.6 20.3 20.0
Aften205 FS 39.1 34.1 31.4 29.0 25 21.5 19.1 17.8 17.6 17.3

Teoric4s ML 43 40 35 30 25 20.5 18.0 15.5 13.0 10.5
SoftEnc. ML 44.0 40 35 30 25 20.6 18.1 15.5 13.0 10.5
Aften205 ML 41.5 39.0 35 30 25 20.0 16.5 14.1 11.6 9.1

Teoric5s MS 39 35.5 33 30 25.5 23 20.9 20.5 20.2 19.9
Teoric4s MS 39 35.5 33 30 25 20.9 20.7 20.5 20.2 19.9
SoftEnc. MS 44.0 37.8 33.1 30 25 21.0 20.8 20.6 20.3 20.0
Aften205 MS 36.6 33.9 31.5 29.0 25 21.5 19.1 17.8 17.6 17.3

Teoric5s SP 33.8 32.8 31.8 30 25.5 23 20.9 20.5 20.2 19.9
Teoric4s SP 33.8 32.8 31.8 30 25 20.9 20.7 20.5 20.2 19.9
SoftEnc. SP 44.0 37.8 31.9 30 25 21.0 20.8 20.6 20.3 20.0
Aften205 SP 41.7 37.6 33.7 29.7 25 21.5 19.1 17.8 17.6 17.3

SoftEncode work like Teoric4s +- 0.1 dB in High volume (range 0-20 dB), in the Low volume range (40-45 dB) never amplify enough.

Aften205 need 3 dB attenuation more at 0 dB (if Teoric5s for FL), in Low volume range there are different behaviors.

[alexander321]

I can't access sources or others revisions, http://jbr.homelinux.org/aften/ don't work for me and http://sourceforge.net/projects/aften is outdated.
Then only can test Kurtnoise13 binarys. The last is Aften rev 205 (Aften205).


Aften-0.05_rev211 ;)
http://kurtnoise.free.fr/Aften/

[tebasuna51]

Thanks.
Same results with Aften rev211.

[LigH]

Aften 0.05 rev221 creates a messed file for me:

- I decoded AC3TEST.AC3 (male saying "L/C/R/RS/LS/LFE") into 6 Mono WAV files.
- Using the MUX wizard in BeLight 0.22b9, I created a MUX file with the WAV preset.
- This MUX file being used as input, I used BeLight and BeSweet 1.5b31 to write a 6ch WAV.

Using AftenGUI 1.2, I created a new 5.1 AC3 file, and played that with MPC and optical digital conection.

- The file created with Aften 0.05 sounded well.
- The file created with Aften 0.05 rev221 sounded "choppy" (like digital sound not being recognised by the decoder) for the left channel (used while saying "Left" and "LFE").

AC3 made with Aften 0.05 (http://www.ligh.de/tmp/AC3Test005.ac3)
AC3 made with Aften 0.05 rev221 (http://www.ligh.de/tmp/AC3Test221.ac3)

[Kurtnoise]

@LigH : could you upload your source file please ?

[tebasuna51]

@Ligh
Bug confirmed. Using my sources the same problem:
Front left channel in ac3 distorted and with LFE mixed.
The rest of channels (LFE also) seems OK.

The bug exist in rev185 (23-10-2006), rev205 and rev211 at least.
The last rev I have and work OK is rev113 (3-10-2006)

[DarkAvenger]

My fault, sorry. Rev 212 contains the fix.

Another thing I noticed: Channel mapping (at least when plaing with xine) is incorrect. Bug of xine or aften? version 0.05 already shows this behaviour.

[tebasuna51]

DarkAvenger here?.

Bug fixed with Rev 212.

Channel mapping always correct with 5.1 ac3, I don't know xine but play ok with Bsplayer (ffdshow) and foobar players/decoders. Also work ok with decoders like Azid 1.9 or NicAudio-AviSynth.

[Archimedes]

Same thing when using BeLight. The following mux file, created with BeLight, works fine for AC3Enc, but not for Aften.

"C:\Temp\5.1-Test\audioFL.wav"
"C:\Temp\5.1-Test\audioC.wav"
"C:\Temp\5.1-Test\audioFR.wav"
"C:\Temp\5.1-Test\audioSL.wav"
"C:\Temp\5.1-Test\audioSR.wav"
"C:\Temp\5.1-Test\audioLFE.wav"

Here are the log files of the encoding processes (using the above mux file).

Encoding with Aften:
BeSweet v1.5b31 by DSPguru.
--------------------------
Using Shibatch.dll v0.25 by Naoki Shibata & DSPguru (shibatch.sourceforge.net).
Using bsn.dll replacement by Dimzon & Kurtnoise, Build Sep 30 2006, 16:58:17

Logging start : 10/29/06 , 13:51:21.

C:\Programme\BeLight\BeSweet.exe -core( -input C:\Temp\5.1-Test\audio.mux -output C:\Temp\5.1-Test\audio.ac3 -logfile C:\Temp\5.1-Test\audio.log ) -bsn( -exe aften.exe -b 384 -6chnew )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : C:\Temp\5.1-Test\audio.mux
[00:00:00:000] | Output: C:\Temp\5.1-Test\audio.ac3
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +---------------------
[00:00:30:000] Conversion Completed !
[00:00:04:000] <-- Transcoding Duration

Logging ends : 10/29/06 , 13:51:25.

Encoding with AC3Enc:
BeSweet v1.5b31 by DSPguru.
--------------------------
Using AC3enc.dll v1.20 (Feb 18 2004) by Fabrice Bellard (http://ffmpeg.org).

Logging start : 10/29/06 , 13:58:04.

C:\Programme\BeLight\BeSweet.exe -core( -input C:\Temp\5.1-Test\audio.mux -output C:\Temp\5.1-Test\audio.ac3 -logfile C:\Temp\5.1-Test\audio_1.log ) -ac3enc( -b 384 -6ch )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : C:\Temp\5.1-Test\audio.mux
[00:00:00:000] | Output: C:\Temp\5.1-Test\audio.ac3
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +------- AC3ENC ------
[00:00:00:000] | Bitrate method : CBR
[00:00:00:000] | AC3 bitrate : 384
[00:00:00:000] | Channels Mode : 5.1
[00:00:00:000] | Error Protection: Yes
[00:00:00:000] +---------------------
[00:00:30:000] Conversion Completed !
[00:00:30:000] Actual Avg. Bitrate : 383kbps
[00:00:02:000] <-- Transcoding Duration

Logging ends : 10/29/06 , 13:58:06.

After changing the order in the mux file, Aften works right.

"C:\Temp\5.1-Test\audioFL.wav"
"C:\Temp\5.1-Test\audioFR.wav"
"C:\Temp\5.1-Test\audioC.wav"
"C:\Temp\5.1-Test\audioLFE.wav"
"C:\Temp\5.1-Test\audioSL.wav"
"C:\Temp\5.1-Test\audioSR.wav"

[DarkAvenger]

Hmm it seems Aften assumes MS channel mapping and not AC3 channel mapping. Must ask Justin, whether he wants to put in an option to make it selectable.

[tebasuna51]

Hmm it seems Aften assumes MS channel mapping and not AC3 channel mapping. Must ask Justin, whether he wants to put in an option to make it selectable.
Of course Aften assumes the standard wav order like input, is a accepted suggestion (http://forum.doom9.org/showthread.php?p=850233#post850233) based in the principle:

"A encoder must know the standard channel order of input files and do any remmaping, if needed, internally."

With a similar principle for decoders:

"A decoder must know the standard channel order of output files and do any remmaping, if needed, internally."

we never have mapping problems. All newer decoders/encoders must respect this principles. Please don't suggest backward steps.

[Rockaria]

Hmm it seems Aften assumes MS channel mapping and not AC3 channel mapping. Must ask Justin, whether he wants to put in an option to make it selectable.
It had been an multi-channel(5.x~) issue happened in many tools(vorbis, nero aac,, ) also, now corrected in most encoders & decoders/players.
When decoded(any format->pcm/wav) and played(pcm/wav) or encoded(pcm/wav->ac3), having steady identical behaviors looks more reasonable to me too.

But the explicit channel mapping plugin/option might be also useful to easy correct the wrong aligned channels.
Better than splitting to 6 mono wavs then renaming/muxing/merging or using other altering tools.

[DarkAvenger]

Well, Softencode prefers AC3 mapping for 6ch WAVs. ;)

@tebasuna51

Aften contains an "WAV decoder" so here the principle applies. And not everything you may think is right needs to be "the right way"... So please don't comment my suggestions with possible offending colour. Thank you.

[tebasuna51]

@DarkAvenger
First of all sorry if my comment can offend you, is not my intention.
I estimate your work with HeadAc3he and, before Aften, always recommend your soft like the best free ac3 encoder.
http://forum.doom9.org/showthread.php?p=797787#post797787
http://forum.doom9.org/showthread.php?p=759503#post759503

Of course my opinion is not necessarily "the right way".
But only want transmit a conclusion generally accepted in this, and others, forums about the channelmapping.

I am not a MS defender but the wav order L-R-C-LFE-SL-SR is a standard "de facto" and is used by many multichannel audio software.

Is true Softencode prefers AC3 mapping but only 3 clicks are needed to process a wav with standard order. Really I need more arguments to change my opinion.

Maybe I'm newbie in audio software and don't know the historical reasons to the existence of different wav order, but we need only one order allowed because there aren't fields in wav header to indicate the actual order. How we can distinguish between two wav's with different order?

Sorry and thanks for your job (headAc3he and now the Aften compilations).

[LigH]

Apropos multi-channel WAV:

I am sure you already once calculated the maximum playing time for a standard WAV file with 6 channels - where the WAV header can only store "data" sizes up to 4 GB. Several movies or especially classic music programmes will probably play longer...

To allow longer input, I would recommend to add some different input - either "extensible" wave files (although I have no clue how to create them; can BeSweet create such files reliably?), or single mono files (maybe via *.mux lists).

[Inc]

imho there does something exist like a type of WaveFormat64 File Type. Those decoders/encoders which do support longer 5.1 Wavs simply do ignore the length member of the waveheader-structure and do transcode till "eof" is reached of the incoming 5.1 pcm data.

[DarkAvenger]

@tebasuna51

OK, no offence taken. ;) But I prefer to have an option. Do you now Gnome? Those are people who prefer to *not* give people an option and think they know better. That's why Linus Torvalds called them interface nazis. ;)

While I don't mind that the standard mapping should be MS way, I think it still should be possible to import non MS mapping, without using a third tool to remap. In AC3 chain software usually writes/reads in AC3 order, so I just see it as necessitiy and not the right way...

As LigH already mentioned the WAV format as such is broken, so infact using a better PCM container would be the right fix...

[tebasuna51]

@Ligh, Aften work, like Inc say, until "eof" is reached ignoring the two fields in wav header (RiffLength and DataLength), then wav > 4GB are allowed like input.

BeSweet can't manage 16 int wav files > 2 GB and don't use WAVE_FORMAT_EXTENSIBLE header, but Foobar, BeHappy and some decoders like faad, tranzcode, ... can output wav > 4GB.

A "legal" solution don't pass for extensible headers (the two fields are also defined with 4 bytes), MicroSoft recommend avi containers for this kind of wav's.

There are only one problem ignoring the two fields in wav header about the length and work until eof, is not mandatory the data chunk must be the last and a wav can have extrachunks at end of file, and can be treated as data if DataLength is ignored.

The solution via *.mux files are in Justin TODO list, see this post (http://forum.doom9.org/showthread.php?p=881800#post881800).

[DarkAvenger]

It seems Kurtnoise13 compiles don't include the SSE(3) routines I patched in from Vorbis Lancer project. (It would be good if you changed to cmake build system. :))

So here is a MinGW compile. It should run on non-SSE CPUs as well. If not, please let me know. Perhaps I should optimize for i586. I don't know whether MinGW/gcc optimizes for i386 by default, which wouldn't be fastest.

(Kurtnoise13: Which compile flags do you use?)

It would be nice to get some benchmarks of sse enabled aften vs plain version vs 0.05 version. Esp if someone has a Core2Duo.

(It could be that the included dll is outdated, but it seems I can't edit my attachment.)

[Kurtnoise]

For public compiles, I don't use extra flags. For my own use I just include -march=k8.

btw, what are the pros and the cons about cmake vs make ?

A small how-to could be great too coz I've several compilers (gcc within MinGW, MSVC6, MSVC8).

[DarkAvenger]

btw, what are the pros and the cons about cmake vs make ?


Wrong question. ;) CMake uses make depending on your platform. CMake is a substitution for configure. Its use is portability. It has support to build Makefiles/project files for various Compilers/IDEs.

So as dev, we just have to maintain CMake - nothing else and it is a lot easier to use than eg autotools or a manual script as Justin used. And as user/distributor you can generate a native project file for his needs (as long as cmake supports it).


A small how-to could be great too coz I've several compilers (gcc within MinGW, MSVC6, MSVC8).

For windows you need cureently CMake built from cvs, as the stable version has a bug with custom languages support.
For that you need (I used mingw to compile cmake):

- mingw (including c++ compiler) ;)
- cvs (best added to path)
- cmake from cvs (see cmake.org download page)

Go into Cmake's root dir type ./bootstrap (or alike) then make and wait. make install will put it into program files and should also add it to path.

Now for aften. I think aou already have the svn version.

- Create a dir (eg def), change into def.

Depending on the compiler you want to use, you need to specify the generator.

So for MSYS/MinGW (in dir def):

- cmake -G "MSYS Makefiles" ..
- make

(You need to manually strip the binaries.)

For MSVC you could try out the various VC generator. I used the Visual C++ 2005 Express edition w/o IDE. for that you need the Platform SDK as well. To get it compiled, start the correct platform sdk env then in the shell start the vc env setting bat

Now to compile aften (using Nmake):

- create a dir (eg vc) and change into vc
- cmake -G "NMake Makefiles" ..
- nmake

That should do it. (Just to note: I don't know if the generator names above are correct. Just type cmake and it wil list available generators. There is also an IDE version of cmake on every platform, eg ccmake for Linux. But I usually prefer command line.)

[Kurtnoise]

Thanks but...


cmake -G "MSYS Makefiles" ..
-- Check for working C compiler: c:/MinGW/bin/gcc.exe
-- Check for working C compiler: c:/MinGW/bin/gcc.exe -- works
-- Check size of void*
-- Check size of void* - done
Could not detect machine type
-- Assuming i386 machine
-- Performing Test HAVE_64BITS
-- Performing Test HAVE_64BITS - Failed
-- Performing Test HAVE_FLAG_STD=GNU99
-- Performing Test HAVE_FLAG_STD=GNU99 - Success
-- Performing Test HAVE_FLAG_WDISABLED_OPTIMIZATION
-- Performing Test HAVE_FLAG_WDISABLED_OPTIMIZATION - Success
-- Performing Test HAVE_FLAG_WFLOAT_EQUAL
-- Performing Test HAVE_FLAG_WFLOAT_EQUAL - Success
-- Performing Test HAVE_FLAG_WBAD_FUNCTION_CAST
-- Performing Test HAVE_FLAG_WBAD_FUNCTION_CAST - Success
-- Performing Test HAVE_FLAG_WDECLARATION_AFTER_STATEMENT
-- Performing Test HAVE_FLAG_WDECLARATION_AFTER_STATEMENT - Success
-- Performing Test HAVE_FLAG_WEXTRA
-- Performing Test HAVE_FLAG_WEXTRA - Success
-- Performing Test HAVE_FLAG_WNO_SWITCH
-- Performing Test HAVE_FLAG_WNO_SWITCH - Success
-- Check if the system is big endian
-- Check if the system is big endian - little endian
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for byteswap.h
-- Looking for byteswap.h - not found
-- Performing Test HAVE_SSE
-- Performing Test HAVE_SSE - Success
-- Performing Test HAVE_SSE3
-- Performing Test HAVE_SSE3 - Success
-- Performing Test HAVE_MM_MALLOC
-- Performing Test HAVE_MM_MALLOC - Success
-- Performing Test HAVE_CASTSI128
-- Performing Test HAVE_CASTSI128 - Failed
-- Using YASM/NASM
-- Performing Test HAVE_NASM_VISIBILITY
-- Performing Test HAVE_NASM_VISIBILITY - Failure
-- Writing config.h
-- Configuring done
-- Generating done
-- Build files have been written to: c:/temp/aften/default

HP_2@LIONEL /c/temp/aften/default
$ make
Scanning dependencies of target aften_static
[ 4%] Building C object CMakeFiles/aften_static.dir/libaften/a52enc.obj
[ 9%] Building C object CMakeFiles/aften_static.dir/libaften/bitalloc.obj
[ 14%] Building C object CMakeFiles/aften_static.dir/libaften/bitio.obj
[ 19%] Building C object CMakeFiles/aften_static.dir/libaften/crc.obj
[ 23%] Building C object CMakeFiles/aften_static.dir/libaften/dynrng.obj
[ 28%] Building C object CMakeFiles/aften_static.dir/libaften/window.obj
[ 33%] Building C object CMakeFiles/aften_static.dir/libaften/mdct.obj
[ 38%] Building C object CMakeFiles/aften_static.dir/libaften/exponent.obj
[ 42%] Building C object CMakeFiles/aften_static.dir/libaften/filter.obj
[ 47%] Building C object CMakeFiles/aften_static.dir/libaften/util.obj
[ 52%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps.obj
[ 57%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_dummy.obj
[ 61%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_common_init.obj
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c: In function `sse_mdct_ctx_init':
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM0' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM2' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM0' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM2' might be used uninitialized in this function
[ 66%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj
In file included from c:/temp/aften/libaften/x86/x86_sse3_mdct_dummy.c:2:
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c: In function `mdct_bitreverse':
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:430: warning: implicit declaration of function `_mm_castsi128_ps'
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:430: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:431: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:432: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:433: error: incompatible types in assignment
make[2]: *** [CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj] Error 1
make[1]: *** [CMakeFiles/aften_static.dir/all] Error 2
make: *** [all] Error 2

compilation failed with minGW. :( Any idea ?

[DarkAvenger]

Thanks for the report. It must be some bug in the code (probably a typo), I'll check, as cmake detects that your compiler doesn't have the mentioned cast function, but tries to use it anyway. Interesting, that it works with my mingw version. :-/


Uhm, could you please post the contents of config.h?

Forget it, I found the bug. When I refactored the code I forgot to implicitly include config.h in the simd support routine, thus no fallback got ever activated... So please svn up for rev 213 and try again.

[Kurtnoise]

Sounds better but not perfect...:)

[ 61%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_common_init.obj
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c: In function `sse_mdct_ctx_init':
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM0' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM2' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM0' might be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM2' might be used uninitialized in this function
[ 66%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj
[ 71%] Building ASM object CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.obj
Linking C static library libaften_static.a
[ 71%] Built target aften_static
Scanning dependencies of target aften_wav
[ 76%] Building C object CMakeFiles/aften_wav.dir/aften/wav.obj
Linking C static library libaften_wav.a
[ 76%] Built target aften_wav
Scanning dependencies of target aften_exe
[ 80%] Building C object CMakeFiles/aften_exe.dir/aften/aften.obj
c:/temp/aften/aften/aften.c: In function `print_help':
c:/temp/aften/aften/aften.c:151: warning: string length `4456' is greater than the length `4095' ISO C99 compilers are required to support
Linking C executable aften.exe
c:/temp/aften/default/libaften_static.a(x86_cpu_caps.obj):x86_cpu_caps.c:(.text+0x41): undefined reference to `_alDetectx86CPUCaps'
collect2: ld returned 1 exit status
make[2]: *** [aften.exe] Error 1
make[1]: *** [CMakeFiles/aften_exe.dir/all] Error 2
make: *** [all] Error 2

[DarkAvenger]

I think you used nasm as assembler, right? I think I used yasm. So I'll check outwhat goes wrong with nasm...

OK, should be fixed now.

[Kurtnoise]

Indeed...it works fine now. Thank you very much.

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften-0.05_rev214.zip

[Kurtnoise]

Hi,

I've made a benchmark regarding encoding speed with a wav sample (44100 Hz - 2Ch - 0:48:26.450 - 488.97 MB) encoded @448kbps :

http://img241.imageshack.us/img241/8757/aftenbenchbi3.png

Note:
OS: WinXP SP2 AMD Athlon 64 3200+ / 2GO Ram
SoftEncode: version 1.0 build 19.
Aften_SSE3_r214 : last svn revision with default SSE flags (gcc compiler with CMake).
Aften_0.05 : version 0.05 with default settings for the compiler (gcc).
Aften_k8_r214 : last svn revision with extra flags (-march=k8 -O3 -pipe -fomit-frame-pointer)
time value in seconds

[DarkAvenger]

Thanks! In fact -O3 and -fomit-frame-pointer (OK this flag set by use in project file) are already set by cmake (though if you override CFLAGS you have to set them again, at least -O3 and -DNDEBUG.) So in the end the march setting gives you a small speed-up. But it's nice to see that svn version is again much faster than last release.

Oh another note: A 64bit compile is about 20% faster than a 32bit one on my x86_64 Linux system.

BTW, you can use "make VERBOSE=1" to see what cmake passes to gcc.

[tebasuna51]

Hi,
I just want to mention that my attempt at DRC encoding has been committed to Aften SVN. If anyone wants to try it out, the commandline option is -dynrng. Below is a snippet from the usage text.

[-dynrng #] Dynamic Range Compression profile
0 = Film Standard
1 = Film Light
2 = Music Standard
3 = Music Light
4 = Speech
5 = None (default)

-Justin
WARNING, also in your Aftenblog:
example using Film Standard:
aften -dnorm 27 -dynrng 0 test.wav test.ac3

example using Music Light:
aften -dnorm 17 -dynrng 3 test.wav test.ac3
But with aften -h we have
[-dynrng #] Dynamic Range Compression profile
0 = Film Light
1 = Film Standard
2 = Music Light
3 = Music Standard
4 = Speech
5 = None (default)
And I think this last is the correct way.
With this last parameters I make my test (http://forum.doom9.org/showthread.php?p=893111#post893111)

[danpos]

@Darkavenger

I'm having some difficulties in order to compile the last svn revision (214). I'm using Ubuntu 'Edgy' GNU/Linux with gcc 4.1.2 / yasm 0.4.0. This is what I got after do a 'checkout' on svn repository:


drwxr-xr-x 3 danpos danpos 4096 2006-10-31 21:54 aften
-rw-r--r-- 1 danpos danpos 2001 2006-10-31 21:53 bswap.h
-rw-r--r-- 1 danpos danpos 2615 2006-10-31 21:53 Changelog
-rw-r--r-- 1 danpos danpos 7611 2006-10-31 21:53 CMakeLists.txt
drwxr-xr-x 3 danpos danpos 4096 2006-10-31 21:54 CMakeModules
-rw-r--r-- 1 danpos danpos 3688 2006-10-31 21:53 common.h
-rwxr-xr-x 1 danpos danpos 18162 2006-10-31 21:53 configure
-rw-r--r-- 1 danpos danpos 26428 2006-10-31 21:53 COPYING
drwxr-xr-x 4 danpos danpos 4096 2006-10-31 21:54 libaften
-rw-r--r-- 1 danpos danpos 1833 2006-10-31 21:53 Makefile
-rw-r--r-- 1 danpos danpos 962 2006-10-31 21:53 README
drwxr-xr-x 3 danpos danpos 4096 2006-10-31 21:54 util

Now, how do I must to use the compilation commands in order to get an optimized version from my machine (Athlon XP 2600+)?

Thanks in advance,

[DarkAvenger]

See first post on this page.

Create your working dir and change into it and try:

CFLAGS="-march=athlon-xp -O3 -DNDEBUG" cmake ..
make

[danpos]

@DarkAvenger

Thanks for your reaction. As a matter of fact, I did read your first post out and seems that I'd not understood it correctly. I follow your advises and so got these results:


root@WOLF:/home/danpos/Pacotes/Aften# CFLAGS="-march=athlon-xp -O3 -DNDEBUG" cmake .
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- works
-- Check size of void*
-- Check size of void* - done
Please do an out-of-tree build:
rm -f CMakeCache.txt; mkdir -p default; cd default; cmake ..; make
CMake Error: Error in cmake code at
/home/danpos/Pacotes/Aften/CMakeLists.txt:15:
MESSAGE in-tree-build detected
Current CMake stack: /home/danpos/Pacotes/Aften/CMakeLists.txt;/usr/share/CMake/Modules/CMakeCInformation.cmake
-- Configuring done


root@WOLF:/home/danpos/Pacotes/Aften# make
Makefile:4: config.mak: Arquivo ou diretório inexistente
touch config.mak
make -C libaften all
make[1]: Entrando no diretório `/home/danpos/Pacotes/Aften/libaften'
make[1]: Nada a ser feito para `all'.
make[1]: Saindo do diretório `/home/danpos/Pacotes/Aften/libaften'
make -C aften all
make[1]: Entrando no diretório `/home/danpos/Pacotes/Aften/aften'
cc -I. -I.. -I../libaften -I/libaften -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -c -o aften.o aften.c
In file included from aften.c:25:
../common.h:105: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘log2tab’
../common.h:120: error: expected ‘)’ before ‘v’
In file included from ../common.h:129,
from aften.c:25:
../bswap.h:37: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bswap_16’
../bswap.h:41: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bswap_32’
../bswap.h:46: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bswap_64’
In file included from aften.c:37:
wav.h:53: error: expected specifier-qualifier-list before ‘uint32_t’
aften.c: In function ‘main’:
aften.c:432: error: ‘uint8_t’ undeclared (first use in this function)
aften.c:432: error: (Each undeclared identifier is reported only once
aften.c:432: error: for each function it appears in.)
aften.c:432: error: ‘frame’ undeclared (first use in this function)
aften.c:440: error: ‘uint32_t’ undeclared (first use in this function)
aften.c:440: error: expected ‘;’ before ‘samplecount’
aften.c:496: error: ‘WavFile’ has no member named ‘channels’
aften.c:497: error: ‘WavFile’ has no member named ‘channels’
aften.c:497: error: ‘WavFile’ has no member named ‘ch_mask’
aften.c:498: error: ‘WavFile’ has no member named ‘sample_rate’
aften.c:503: error: ‘WavFile’ has no member named ‘read_format’
aften.c:514: error: ‘WavFile’ has no member named ‘channels’
aften.c:520: error: ‘samplecount’ undeclared (first use in this function)
aften.c:520: error: ‘bytecount’ undeclared (first use in this function)
aften.c:520: error: ‘t0’ undeclared (first use in this function)
aften.c:520: error: ‘t1’ undeclared (first use in this function)
aften.c:520: error: ‘percent’ undeclared (first use in this function)
aften.c:525: error: ‘WavFile’ has no member named ‘channels’
aften.c:538: error: ‘WavFile’ has no member named ‘sample_rate’
aften.c:539: error: ‘WavFile’ has no member named ‘samples’
aften.c:541: error: ‘WavFile’ has no member named ‘sample_rate’
aften.c:546: error: ‘WavFile’ has no member named ‘samples’
aften.c:547: error: ‘WavFile’ has no member named ‘samples’
aften.c:569: error: ‘WavFile’ has no member named ‘sample_rate’
make[1]: ** [aften.o] Erro 1
make[1]: Saindo do diretório `/home/danpos/Pacotes/Aften/aften'
make: ** [progs] Erro 2

Any ideas?

Thanks in advance,

[DarkAvenger]

Why don't you *read*? YOu need to create a work dir!

[danpos]

Why don't you *read*? YOu need to create a work dir!

Thanks, I think that now I did *read* it out correctly. :)

Regards,

[sdsumike619]

I just discovered this encoder from someone else. Can someone tell me what settings to use, boxes to check, etc. in order for me to be able to encode a regular wav file (no surround 5.1 or anything like that). I also want to encode the AC3 so that it has the same volume throughout as the original wav did.

It seems everytime I encode an AC3, no matter what software I'm using, the volume is always much lower. So someone on a another forum told me to use Aften and it could accomplish what I needed.

Thanks for the input

[Kurtnoise]

Can someone tell me what settings to use, boxes to check, etc. in order for me to be able to encode a regular wav file (no surround 5.1 or anything like that). I also want to encode the AC3 so that it has the same volume throughout as the original wav did.
Just use default settings...


btw, does anybody is interested by an update of the GUI ? To test mainly the dynamic range compression profiles...

[raquete]

btw, does anybody is interested by an update of the GUI ? To test mainly the dynamic range compression profiles...
i am Kurt,just tell me what to do and what you really want to know about the results.
i have lots of sources for test.
please update the GUI,is my favorite tool! :)

[LigH]

Of course we are interested. For example, in the german doom9/Gleitz board, a thread about recommendable settings was just started by katjarella, and Archimedes1 seems to know a good amount of background.

http://forum.gleitz.info/showthread.php?t=31827

[Kurtnoise]

Eine englische Übersetzung bitte...xD

So, AftenGUI 1.3 is available (http://kurtnoise.free.fr/index.php?dir=Aften/&file=AftenGUI-1.3.zip)...

changes : added DRC Profiles & Bits Allocation options.

[raquete]

Big thanks kurt.

[jruggle]

I can't access sources or others revisions, http://jbr.homelinux.org/aften/ don't work for me and http://sourceforge.net/projects/aften is outdated.

Hi all,
Sorry the daily builds are not working. My internet connection went down last week and due to financial constraints it may be another week or so before I'm back online. I'm posting now from the local library. I'll check back periodically to answer any questions that may come up.
-Justin

[DarkAvenger]

I am currently parallelizing aften. :) At least after hours of struggling I got the main locking to work. (I "never" used pthreads before and linux scheduling regarding threads is quite unfair.) While there is still some locking for some critical regions missing (ie output is distorted, but I know where it is missing), it seems to work now.

So on my dual core, encoding time for a test sample went down from 8sec to 4.9sec, which isn't too bad. It will probably be a bit slower once everything is correctly locked, but there is some room for optimization.

Are here any Linux users with dual core systems? Once I got it working (perhaps this week-end; I have a full time job now, so less time for hobbies) I'd like to have some testers. Just send me a pm with email addy and I'll contact you once I got something ready.

Oh, and does anybody know (in a portable way) how to find out at run-time, how many physical cores are available?

Of course I'll try to make it portable/win32 compatible. ;)

[Edit]
So, I managed to get binary identical output from the threaded version. So, I'll see whether I get it working in win32 and clean up the mess... Furthermore it seems I found some sort of bug in the bitalloc.

I needed to revert http://svn.sourceforge.net/viewvc/aften/libaften/bitalloc.c?r1=77&r2=78 to get identical results. (Un)Applying that patch gives me different results even with single-threaded version. So is the search faulty or is the "better start estimate" faulty? Justin?

[Edit]
OK, I got the Win32 Version going as well. But I noticed my gcc3.4 for mingw miscompiles it. Using msvc works and mingw-crosscompiler for linux based on gcc 4.1.2 works as well. I found gcc 4.1.1 (http://gda.utp.edu.co/~ceniza/GCC-4/4.1.1/) binary for mingw, which works as well. So time to ditch gcc 3.4.... As I don't have Windows installed on my dual core, I couldn't test whether the threading actualy works as promised. Using Wine under Linux it seems it does, though not as effective as the pthread version. (It seems windoes doesn't provide an equivalent to the pthread condition variable, so I used events. Well, Windows Vista seems to support the cond var, so converting pthread apps to vista seems to be straight forward...)

I found some means to detect number of available cpus, which I want to integrate, then I'll release some bins and an (unclean) patch.

[Edit]
Here it is: http://mitglied.lycos.de/darkav/download/aften_parallel.zip
You need to visit darkav.de.vu first and paste above url, otherwise you can't access the file.

[Kurtnoise]

*bump*...Does anybody have tested the parallel build from DarkAvenger ? Download mirror here (http://kurtnoise.free.fr/Aften/)...

btw, compilation failed with rev 215 :
[ 66%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj
In file included from c:/temp/aften/libaften/x86/x86_sse3_mdct_dummy.c:2:
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c: In function `mdct_bitreverse':
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:430: warning: implicit declaration of function `_mm_castsi128_ps'
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:430: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:431: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:432: error: incompatible types in assignment
c:/temp/aften/libaften/x86/x86_sse_mdct_common.c:433: error: incompatible types in assignment
make[2]: *** [CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj] Error 1
make[1]: *** [CMakeFiles/aften_static.dir/all] Error 2
make: *** [all] Error 2


edit: mmh...compilation is fine with gcc 4.1.1 but not with 3.4.5.

[DarkAvenger]

gcc 3.4.5 doesn't provide the _mm_castsi128_ps intrinsic, but cmake should detect it and activate the work-around. I don't get why it breaks now. Could you mail/post the generated config.h? Another thought: Is there some other config.h around (eg in aften root)? This could be a trouble-maker, as well. I added the binary dir first in the CMake project file now, which should fix this.

BTW, cmake 2.4.4 was released. I haven't tested yet, but perhaps this version doesn't segfault anymore, so cvs cmake wouldn't be needed on windows?

[Kurtnoise]

Another thought: Is there some other config.h around (eg in aften root)? This could be a trouble-maker, as well.
aaa yes...That was the problem. Thanks. It works fine now.

BTW, cmake 2.4.4 was released. I haven't tested yet, but perhaps this version doesn't segfault anymore, so cvs cmake wouldn't be needed on windows?
I used to use always the last cvs checkout. So, no problem with this.

[raquete]

@ Kurt
please,can you give me a deep explanation to adjust the Misc tab,the Filters & Overrides Tab in AftenGUI1.3?
and what After version i use with this GUI?
i really need and apriciate your help.

strange comparison with Creedence - Pagan Baby:
-31dB adjusted / DRC none...same source(.wav)
vegas: AC3 start too loud(crispy) and descrease few seconds later
sfsencode: AC3 start loud,decrease few seconds and when the voice start decrease the volume a little more.
AftenGUI1.1: volume start normal and stay normal in the whole music just like the source!
in the end....trashing vegas and sencode again and calling for help to adjust the tabs,like i'm doing now.

best regards!
:)

[Skelsgard]

Could you post a 30 secs clip of the original WAV for that Credence song?

Cheers

[raquete]

of course.
do you want with fade out or abrupt cut?

[Skelsgard]

Abrupt cut will do just fine. I´m more interested in the section where you find the volume inconsistencies between encoders.

Cheers.

[raquete]

here it is Skelsgard: http://rapidshare.com/files/5007399/raq01.rar.html

the issue happen in the begining of the music where the singer start to sing with softencode and vegas.
i reinstall softencode and using this little sample the issue happen again.
vegas is trashed forever...who needs of 172Mb installed to get audio issues? lol

with AftenGUI1.1 using aften.exe from 7/30/2006 the resulting sound is perfect!!!
thanks for your interest! :)

@ Kurt
my friend,without guide i got cool results,now imagine what i can get if you answer my requests of the adjusts in AftenGUI1.3
:thanks:

[Skelsgard]

I´ve tested the sample and it was impossible for me to find these inconsistencies between encoders using the same parameters.
I´m posting the options used for each program, and in the next post the results (AC3s and decoded WAVs).

Aften 0.05 - Rev. 214
http://img168.imageshack.us/img168/8181/aften01qp7.jpghttp://img490.imageshack.us/img490/7334/aften02cp0.jpg
http://img212.imageshack.us/img212/9213/aften03eg6.jpghttp://img177.imageshack.us/img177/5536/aften04gh6.jpg

Soft Encode
http://img216.imageshack.us/img216/9730/softencode01pp3.jpg
http://img216.imageshack.us/img216/737/softencode02mt7.jpg

Vegas 7
http://img175.imageshack.us/img175/4807/vegas01eg2.jpghttp://img83.imageshack.us/img83/6606/vegas02jg2.jpg
http://img175.imageshack.us/img175/1368/vegas03kf6.jpghttp://img175.imageshack.us/img175/4472/vegas04zu7.jpg

Cheers.

[Skelsgard]

These are the AC3 files obtained:
Aften AC3 http://www.badongo.com/file/1783659
Soft Encode AC3 http://www.badongo.com/file/1783694
Vegas AC3 http://www.badongo.com/file/1783695

These are AC3-decoded WAVs:
Aften http://www.badongo.com/file/1783753
Soft Encode http://www.badongo.com/file/1783791
Vegas http://www.badongo.com/file/1783862


These are the peak files generated from the AC3-decoded WAVs, in order from top to bottom:
- Original
- Aften encoded
- Soft Encoded encoded
- Vegas 7 Encoded
http://img85.imageshack.us/img85/53/peakspu6.jpg

The WAVs were decoded with Soft Encode thru Open --> Dolby Digital (decode to .PCM).
No apparent difference between the files can be noticed at first sight in the peak images. More subtle differences might be found due to the inherent caracteristics of the encoders.

The difeerences you find strike me as odd. You may have been using DRC in the Vegas and Soft Encode samples, raquete.
Could you test again with the options given in the pics?

Cheers.

Edited:
I´ve just realized that the Vegas sample was encoded as 48kHz. This are the 44.1 kHz samples.
AC3 http://www.badongo.net/file/1784039
Decoded http://www.badongo.net/file/1784067

[raquete]

wow..don't need it all.

differences and problems:
you used aftengui1.3,i used aftengui1.1(re read my posts)
you adjusted in the gui to 192Kbps, i to 448Kbps
you encoded AC3-2.0,i 5.1!
dial.norn -31 are equal mine
Aftengui1.1 don't have adjusts like 1.3 version,then...

as you encoded 2.0 lots of adjusts in softencode are differents.
how was used:
448Kbps
48K
3/2 lfe unchecked
complete main
-31dB
20.30KHz
-3dB center mix
-3dB surround mix
copyright bit
original bit stream
info exists
mix level 95 dB SPL
small room flat monitor
DC highpass filter
Bandwidth low-pass filter
You may have been using DRCno DRC(none)! we are changing informations,see what i posted-31dB adjusted / DRC none...i was clever.

The WAVs were decoded with Soft Encode...as i'm scared about softencode i don't will use it to decode.
Could you test again with the options given in the
pics?no,is needed to follow the adjusts that i posted to reproduce the issue and,as you read,don't have anything wrong in the adjusts that i used and no more vegas,was trashed.install 172Mb again to do a single test is too much for my beauty. lol
i will host the results.
softencode and aftengui1.1 only ok?

big thanks for your tests but we have to restart :p

edit: typos

[tebasuna51]

@raquete, I make the test with your sample but using Aften, SoftEncode and Scenarist (I haven't Vegas).

Like Skelsgard I don't found significative differences between the three encodes. I use the same parameters than Skelsgard and don't understand your differences:

- The sample is stereo then must be encoded like 2.0, with 192 Kb/s (default for 2.0)

- The sample is 44.1 KHz and must be encoded without change, in Aften you can't modify the samplerate, but in SoftEncode if you modify the samplerate to 48 KHz SoftEncode assume the original samplerate is 48 KHz (don't make any translation, check the duration).

- Other SoftEncode parameters must be the same than Aften then:
Don't use DC highpass filter
Don't use Bandwidth low-pass filter
And DRC(none) is the same than DRC none... (BTW using or not DRC in encode phase is the same if DRC is not used in the decode phase)

- At last I used Azid (without DRC) to decode the three ac3. SoftEncode can be used if you select in decoder options:
Dynamic Range Compression: Custom mode, analog dialog norm.

I think the problem can be the 44.1 KHz <-> 48 KHz

[raquete]

dear friend tebasuna,
is hard to answer what you can imagine how i did.
i was clear in what i posted and how was done.
the source is stereo because Skelsgard was asking for the source (read his post how he needed the source) but i extract channels and did ac3 5.1 in 48K.
as i can't explain in clever words, better is screenshots and my samples from sources(LR,CLFE,Ss)waves and the ac3 results from aften and from softencode.
then you will see the adjusts used in softencode and hear clearly the issue!
just give me few minutes. :)

[raquete]

ok,here they are:
sources (LR,CLFE,SLSR) : http://rapidshare.com/files/5144213/sources.rar

AC3 from AftenGUI1.1 : http://rapidshare.com/files/5142068/aftengui.rar

AC3 from softencode : http://rapidshare.com/files/5142468/softencode.rar

now hear what happens in 22 seconds when the singer start to sing in the AC3 files,compare with the source and tell me what is equal,what is different.

adjusts used in softencode.
the manual recommend to use DC highpass filter and Bandwidth low-pass filter,then i can't see reason to uncheck this options

http://img292.imageshack.us/img292/6126/01softencodesh9.png

http://img450.imageshack.us/img450/4337/02softencodefo7.png

now please,use the sources posted,adjust softencode like the pictures and compare the results.

[Skelsgard]

You came out somewhat agressive on that last post to me.
This is what you wrote:
strange comparison with Creedence - Pagan Baby:
-31dB adjusted / DRC none...same source(.wav)
vegas: AC3 start too loud(crispy) and descrease few seconds later
sfsencode: AC3 start loud,decrease few seconds and when the voice start decrease the volume a little more.
AftenGUI1.1: volume start normal and stay normal in the whole music just like the source!
in the end....trashing vegas and sencode again and calling for help to adjust the tabs,like i'm doing now.

In no place you state that you´ve upmixed it to 5.1 or any other parameters other than -31dB and DRC none nor that you´ve encoded using previously stated options, so I assumed that you´ve tested all programs with the same parameters, respecting the caracteristics of the audio (channel number, bandwidth, etc).

So, using the parameters from the pics given by raquete...
these are the AC3 samples obtained:
http://www.badongo.com/file/1786841
http://www.badongo.com/file/1786842
http://www.badongo.com/file/1786843

a peak image of all four WAVs (this time decoded with a non-biased decoder: BeHappy) in order from left to right:
raquete´s sample - Aften - Soft Encode - Vegas
http://img244.imageshack.us/img244/1479/peaks51ar7.jpg

Again, no visual or audible differences.

Cheers.

[raquete]

You came out somewhat agressive on that last post to me.never..please excuse is my poor english or some differents regionals language issues.
excuse please,i still don't read the remainder of your post but was afraid of what you are feeling.
excuse me

[raquete]

i re read my old post and don't read nothing agressive against you,see that was not edited!

about your screenshots: i see differences(phases,levels...),even the little lfe show clear differences.

your ac3 samples: the ac3 softencode sample have the same issue in 22 seconds where the singer start.
the sound compress/normalize(fast decay in the whole music in this moment),exactly like in my sample.
another detail is that you adjusted softencode to 105dB SPL(in my screenshot show 95)
i play the samples in mpclassic and in neroshowtime!!!

someone could download and hear the samples,please?
tebasuna?

[tebasuna51]

I know you aren't agressive, maybe a little vehement in yours comments and admit, in your first post are not clear the test parameters.

After that, yes, I download the samples and like Skelsgard I don't found visual differences but seems there are clear audible differences at singer start (22 sec).

I say "seems" because I have attached a old audio equipment with only DPL I decoder and to play 5.1 audio I need:
5.1 -> ffdshow -> dpl I -> Audio Eq -> 6 speakers
To hear 5.1 I need burn a CD/DVD and go out my PC place. Maybe tomorrow.

Then seems there are real differences. And I reproduce the encodes with same issue. I tested with/without filters in SoftEncode. Also with Mid/Side versus Independent in AftenGui -> Misc -> Stereo ReMatrixing (I don't know if is used in 5.1, but in 2.0 make different result).

To be continued...

[raquete]

I know you aren't agressivethanks for recognize and for the friendship.

in your first post are not clear the test parameters.the first intention was to tell about the issues and second that was used the same parameters in the encoders...of course i forgot about channels,was not important in that moment.

Maybe tomorrow. ... To be continued...all right,waiting for you and for Skelsgard.

regards

[Skelsgard]

Is just a trivial misunderstanding.
About my tests, I´ll check again, might have missed something there.
If I can, I´ll try to check with Vegas 6 encoder, but not possible right now.

Cheers.

[Skelsgard]

I´m playing thru BSPlayer with AC3filter 1.09 and honestly can´t hear any difference between the samples as either 5.1 nor downmixed 2.0.
I´m gonna try to ABX them later.

Cheers.

[raquete]

hy.
I´m gonna try to ABX them later.my preference is your ears only.
later(another thread?) we talk about ABX ok? ;)

[raquete]

from Skerlsgard's AC3 samples... http://forum.doom9.org/showthread.php?p=907623#post907623

open one by one in differents pages:
aften: http://img82.imageshack.us/my.php?image=credenceaften51hq4.png
softencode: http://img90.imageshack.us/my.php?image=credencese51hi3.png
vegas: http://img90.imageshack.us/my.php?image=credencevegas51fs9.png

the same screenshots from:
aften:
http://img82.imageshack.us/img82/6075/credenceaften51hq4.png

softencode:
http://img90.imageshack.us/img90/628/credencese51hi3.png

vegas:
http://img90.imageshack.us/img90/8144/credencevegas51fs9.png

each vertical line mark 10 seconds,see how change after 22 seconds,in se and vegas the sounds seems compressed.
from aften is like the source:where the sound is low remains low,where encrease remains encreasing and where is loud remains loud.
i clearly see differences...(listenig too)

i need comments and i'm still waiting one little "how to" to use adjust the AftenGUI1.3 and what means each adjust in the tabs...please!

thanks so much
;)

[Skelsgard]

I´ve re-tested the samples and I absolutely see the difference you´re talking about. I can´t understand how I´ve missed it. Probably the short display of the peak files led me to confussion.
I still have trouble finding audible differences between Aften and Vegas AC3 samples, even in the Soft Encode sample too. At least, in the "compressed" way you talk about.

Cheers.

[DarkAvenger]

I uploaded an updated patch of parallelized aften (against rev 216):

http://mitglied.lycos.de/darkav/download/aften_parallel2.zip

(again, visit darkav.de.vu first. I was too lazy to include binaries this time. ;) Please don't compile with mingw gcc3.4, use gcc 4.x.)

- buildable without threads
- if one cpu (core) is detected, unthreaded version is used
- mdct uses one global context and per thread buffers, instead of duplicating tables to every thread

I really hope Justin gets his internet connection back, so that he can review it and I can start merging this stuff...

[raquete]

impossible to download aften_parallel2.zip.
something wrong in lycos.de (message from IE)

[DarkAvenger]

See what's written below the link. You must paste the address after vising the home. It is an anti-leech protection.

You also read that no binaries are included, ie you have to compile yourself?

[DarkAvenger]

Probably the last functional update (again, patch only):

http://mitglied.lycos.de/darkav/download/aften_parallel3.zip

- parallelized filter stage using more locks

In fact now aften should now be completely parallelized. Only more clean-ups for merging are left.

[wisodev]

I have builded 64 bit version executable of AFTEN R216 including SSE and SSE3 asm optimization for Windows 64 bit.

Download: BINARIES (http://prdownloads.sourceforge.net/win32builds/aften-svn-r216-win64_sse3-bin.zip?download) | SOURCES (http://prdownloads.sourceforge.net/win32builds/aften-svn-r216-win64_sse3-src.zip?download)

My other builds of AFTEN can be found here (http://win32builds.sourceforge.net/aften/index.html).

[Pookie]

Hi Wisodev :) Welcome to Doom9 forums.

Thanks for your binaries. I like your "FrontEnd" application as well. It looks easy enough to modify the presets and xml so it can work on many different kinds of conversions.

[wisodev]

Hi Wisodev :) Welcome to Doom9 forums.

Thanks for your binaries. I like your "FrontEnd" application as well. It looks easy enough to modify the presets and xml so it can work on many different kinds of conversions.

Thanks.

theForntend is developed with easy usage as a goal (but advanced features are available too ;-)

I am working on new way of handling presets to enable more flexibility, but this is still under development.

About the 64 bit binaries of AFTEN. If anyone has provided some test with my binaries, please send me feedback. I will be grateful for speed and output quality test results (checking if output files are same as 32 bit version is producing).

wisodev

[DarkAvenger]

(checking if output files are same as 32 bit version is producing).


I highly doubt it. Linux and Windows x86_64 uses SSE registers by default - even for scalar operations, while x86 uses i387 by default.

BTW, I would be interested how you compiled the 64 binaries. Did the cmake build system work there, as well? Do you want to try my parallelized version, as well?

[Kurtnoise]

iirc, wisodev uses the ICL compiler...

[DarkAvenger]

cmake works with ICL (at least tested on Linux) as well, or what do you refer to?

[Kurtnoise]

I meant MSVC8 + ICL...Sorry.

[wisodev]

BTW, I would be interested how you compiled the 64 binaries. Did the cmake build system work there, as well? Do you want to try my parallelized version, as well?

Check the build scripts in source package. I am using simple batch scripts for ICL 9.1 and MSVC 8.0 (using cross compiling for 64 bit architectures).

I will try to compile your version this weekend as I will have more free time. I will post results here.

Thanks,
wisodev

[wisodev]

Do you want to try my parallelized version, as well?

I have small problem with your sources, I can't find threading.h header file?

[DarkAvenger]

Oh, all right. I forgot that svn di doesn't list newly added files...too bad it slipped my check. I'll add that file to the zip file and reupload.

OK, should be done, please try again.

[wisodev]

Oh, all right. I forgot that svn di doesn't list newly added files...too bad it slipped my check. I'll add that file to the zip file and reupload.

OK, should be done, please try again.

I downloaded file http://mitglied.lycos.de/darkav/download/aften_parallel3.zip but I don't see any new files. Can you post missing files in post here.

[DarkAvenger]

Ok, now it works, I made sure. Sorry for the hassle. Problem of attaching files here is, they must be made accessible by the admins...which could time...

[wisodev]

Ok, now it works, I made sure. Sorry for the hassle. Problem of attaching files here is, they must be made accessible by the admins...which could time...

OK I have downloaded the archive with threading.h and now I can start building binaries.

Thanks,
wisodev

[wisodev]

I have builded 64 bit version executable of AFTEN R216 including SSE and SSE3 asm optimization for Windows 64 bit using parallelized version by Prakash Punnoor (original sources (http://mitglied.lycos.de/darkav/download/aften_parallel3.zip)).

Download: BINARIES (http://prdownloads.sourceforge.net/win32builds/aften-svn-r216-mt-win64_sse3-bin.zip?download) | SOURCES (http://prdownloads.sourceforge.net/win32builds/aften-svn-r216-mt-win64_sse3-src.zip?download)

Thanks,
wisodev

[ADLANCAS]

how's development coming? (32bit) :)

[tebasuna51]

how's development coming? (32bit) :)
Seems stopped.
After this post (http://forum.doom9.org/showthread.php?p=897950#post897950) Justin is missing. Maybe is discouraged for the little feedback about DRC?.

[DarkAvenger]

He is still waiting for getting his internet access back...

[jruggle]

He is still waiting for getting his internet access back...
Indeed I am still waiting. Development has not stopped though. Just in the last week I've been doing some work on Aften. I reimplemented a completely new exponent strategy decision algorithm. Some of the bit allocation parameters have also been tweaked. The big news is that I have channel coupling about 90% working! Right now it decodes without error, but one channel ends up with noise for some reason. I hope to get that fixed in the next day or two. I do need my internet back to continue the work on DRC for the online references, but that won't be too long hopefully.

-Justin

[vlada]

Hi Justin,
I have one question. I'm working on a GUI application which should be able to open almost any video file and convert it to DVD-Video. It will be using AviSynth as the basic engine. I'd like to use Aften to compress a sound to AC3. Can I use AviSynth script as source for Aften? If not, is AviSynth input in you to-do list? Thank you.

[tebasuna51]

@vlada
sh0dan is working to encode ac3 inside AviSynth script:
http://forum.doom9.org/showthread.php?p=925907#post925907

and i think he want use Aften library http://forum.doom9.org/showthread.php?p=920344#post920344

[Pookie]

vlada -

bepipe.exe --script "import(^avisynth.avs^)" - | aften.exe -v 0 - -b 256 ac3file.ac3

Too bad Bepipe needs .NET 2.0. sh0dan to the rescue? ;)

[Mug Funky]

avs2wav :search:

"c:\path\to\avs2wav.exe" "%~1" - | "c:\path\to\aften\aften.exe" -b 224 -s 1 -m 1 -w 45 -dnorm 27 - "%~dpn1.aftend.ac3"

that's the line i use. it's suitable for putting in a batch file.

[edit]

@ jruggle - good news on the channel coupling! once that and DRC are going this will be my preferred encoder, at least for my own stuff (you can't use a non dolby certified encoder on a DVD and be entitled to put the double-D logo on the disc)

[tebasuna51]

avs2wav :search:

"c:\path\to\avs2wav.exe" "%~1" - | "c:\path\to\aften\aften.exe" -b 224 -s 1 -m 1 -w 45 -dnorm 27 - "%~dpn1.aftend.ac3"

avs2wav don't work for me.
I found avs2wav-v1.1.zip who say me:
avs2wav v1.1 by Jory Stone <jcsston@toughguy.net>, stdout patch by kassandro
Input: d:\Programa\Audio\0\Audio.avs
Output: -
Scanning for Audio Stream...

Gaining with a factor of 1.0000 ...
but the output file is always empty.

And kassandro's avs2wav.rar who say me:
Don't found MSVCP70.dll

Bepipe works without problems for me.

[Mug Funky]

MSVCP7x dlls can be found with virtualdub, and a few other programs. if a system search doesn't turn it up, try google or something. it does suck to need runtimes though...

once you find these dll's, either put them somewhere in path, or just in the directory with the program that requires them.

[tebasuna51]

@Mug Funky, thanks for your answer but still don't work for me.

For don't interfere with Aften thread, I reopen the old thread
Wanted: avs2wav (http://forum.doom9.org/showthread.php?p=926685#post926685) to continue this topic if any is interested.

[jruggle]

Hi all,
Just wanted to vent my enthusiasm. :) I got channel coupling working. I'll be able to apply the changes within the next week (as soon as AT&T gets my DSL turned on). It's pretty basic right now because I don't have much to go on as far as the best encoding algorithm to calculate the coupling channel and coupling coefficients. The spec gives a basic idea, but the implementation is not quite so straight-forward.

The plan is to eventually have an adaptive coupling strategy for each frame, but for now I just picked one for stereo and one for multi-channel based on some samples from DVD's. It will just take more analysis of professionally-encoded AC3 files to figure out the best way forward.

On that note, I also got my AC3 frame analyzer working 100% now. It's in the basic preliminary stages, but will eventually be able to do fun stuff like modify metadata, DRC, etc... of existing AC3 files.

-Justin

[BigDid]

Hi all,
Just wanted to vent my enthusiasm. :)
...
On that note, I also got my AC3 frame analyzer working 100% now. It's in the basic preliminary stages, but will eventually be able to do fun stuff like modify metadata, DRC, etc... of existing AC3 files.

-Justin
Happy new year and all my best, glad to read the good news, I'll be waiting for it.

Did

[Mug Funky]

will eventually be able to do fun stuff like modify metadata, DRC, etc... of existing AC3 files

ach! now you're just teasing :). i'm not sure if a tool like this exists anywhere, commercial or otherwise, but it's certainly going to be an extremely useful tool.

happy new year and thanks heaps for keeping this going.

btw, the channel coupling looks good. analysing existing DVDs seems like a good way to do things. one thing though - try checking out movies of the whole spectrum (particularly budget). i've noticed that lower budget movies have rather predictable, generic 5.1 mixes that could help you.

[raquete]

encoding with Aften have more presence and quality in the audio than using softencode in my taste but i'm having only one issue: authoring musics with dvdlab,gui for dvdauthor or with a single audiodvdcreator give too big click between tracks.
if i use the poor ac3 encoder inside audiodvdcreator the sound is worse(less levels/presence) comparing with Aften but don't have clicks or issues,the passages are clean and soft.
was hard to find what could be the reason,only after encoding with another ac3 encoder i could compare the results.
if someone want samples(lots of people don't like)i can host with clicks(from aften)and clean(from audiodvdcreator) results authored in video_ts folder.
anyone have one hint to help me?

[Mug Funky]

i've not encountered clicks using spruce's AV sync track to join audio, nor from binary merging ac3's created by aften.

could you go over your workflow a little? programs etc.

clicks between assets could be wav headers being encoded as audio, or it could be something else.

[raquete]

clicks between assets could be wav headers being encoded as audio...i was clear and was happening.authoring the same sources using Aften(14-07-06)have clicks but not using advdc.
after change to Aften-0.04(2006-Aug-06)no more clicks...seems the solution and deserve more tests,i'm doing!
it all takes me to one question: i'm using the GUI.what Aften version i have to use?
regards

[raquete]

Mug Funky,
i authored 4 full albums in "Gui for dvdauthor" using Aften-0.04 and all is fine,no more clicks. ;)
can you tell me what Aften version are you using and if this version works fine with AftenGUI?
thanks so much!

[Mug Funky]

i think it's .05 - i just noticed it doesn't tell me the version number with aften -h

file is 60,928 bytes, created on wed 23/08/06, 10:56:44 am

i don't know if it works with aftenGUI - i only do 224kbps stereo encodes with it, so i don't need a GUI :)

[tebasuna51]

The last version in http://sourceforge.net/projects/aften (Justin compiles) is:
aften.exe v0.05 21/08/2006 58368 bytes

But after Justin was add the DRC support at 23/10/2006 with daily builds.
Now I can't access Justin compiles (http://jbr.homelinux.org/aften/daily/).

There are KurtNoise/DarkAvenger compiles at http://kurtnoise.free.fr/index.php?dir=Aften/ :
...
aften-0.04 06/08/2006 44032 bytes
aften-0.05 23/08/2006 52736 bytes
aften-0.05_rev214 30/10/2006 679676 bytes
aften-0.05_rev216 23/11/2006 127261 bytes
...
AftenGUI-1.2 for Aften 0.04
AftenGUI-1.3 for Aften 0.05 (+ DRC)
...
Between 3/10 and 30/10 there was some rev with bugs, see http://forum.doom9.org/showthread.php?p=893510#post893510

To see differences between version you can see the blog (http://aftenblog.blogspot.com/).
For work with DRC we can use AftenGUI-1.3 and 0.05_rev216.

[raquete]

first....thank you both for answers!
a long time i call for one Aften little guide...as it "never came" i have one (or two) more questions/doubts: i always adjust DRC to "none" because i encode only musics in 5.1. i have all Aften's versions here and all AftenGUI's saved.
please tell me what version i have to use with the GUI.
thanks.

[tebasuna51]

You can use:
AftenGUI-1.2 for Aften 0.04 or 0.05 (before 23/10/2006)
AftenGUI-1.3 for Aften 0.05 (DRC, 23/10/2006 and news)

the first rev with DRC I have is v0.05_rev185 (23/10/2006) from KurtNoise site, but is buggy (until rev_211). The first ok is rev_212 (29/10/2006) but the recommended is rev_216.

If you don't need DRC you can use AftenGUI-1.2 with last Justin version aften.exe v0.05 21/08/2006 58368 bytes (works fine for me).

[raquete]

woo...thanks,now is very clear!

[wisodev]

I've builded latest Aften binaries from SVN sources at revision 224. The binaries can be downloaded from my website (http://win32builds.sourceforge.net/aften/index.html).

[raquete]

@ tebasuna51
i can feel but i still can't proove that aften 0.05 results are "rispids" but clean with 0.04 version.to feel is needed to relax and listen one know and clean but powerfull source like king crimson or seamless....mfsl or from hdcd sources if possible.
if you don't mind can you do few tests please?

[tebasuna51]

@raquete
My ears can't appreciate any diference (I'm sure the problem is in my ears).

Checking the waveforms I see little differences between original and encodes with 0.04, 0.05. Maybe there are problems using 0.05 and mid/sid rematrixing (default).

Try using 0.05 and independent L+R channels (-m 0), seems work better for high bitrates.

BTW Justin is working in channel coupling now. Maybe there are changes in next version.

[raquete]

ok,i will try independent L+R channels.
waiting for the news too!
thanks for your tests.

[Chainmax]

...
BTW Justin is working in channel coupling now. Maybe there are changes in next version.

Great news, I will finally ditch Scenarist's encoder and switch to AftenGUI as soon as a version with channel coupling is released :). Thanks for all the hard work Justin, and thanks for the compiles and updates, tebasuna51 http://smilies.vidahost.com/otn/wink/thumb.gif.

[jruggle]

BTW Justin is working in channel coupling now. Maybe there are changes in next version.

Yes, version 0.06 is forthcoming, and maybe it will solve the problem...if we're lucky...otherwise I'll try to reproduce your issue & see if I can figure it out.

Version 0.06 will pretty much be an SVN snapshot once a couple small issues get sorted out. It will not have channel coupling. Prakash is still working on parallel encoding, and we want to get that applied first since the channel coupling will be a large commit affecting several files. Both of those changes will be post-v0.06. The Changelog (http://aften.svn.sourceforge.net/viewvc/*checkout*/aften/Changelog?revision=240) in SVN gives a good idea of what will differ between 0.05 and 0.06.

There are many other good things on the TODO list as well. I've recently been playing around with adapting twolame's psychoacoustic model 3 (model 1 from the mpeg spec) for use with Aften. I've got the psych model working...now I just have to implement delta bit allocation in order to take advantage of it. Anyway, there is so much I'm working on it's a bit overwhelming. I'm just taking it one step at a time as far as integration to svn, but in the meantime I'm testing out more features.

-Justin

[Mug Funky]

if you're into psy-models, you might want a look at the Musepack one. it's a codec derived from mp2 (32 subbands and all that), but manages to score slightly more efficient than much more advanced codecs when aiming for transparency.

not sure how much of it would be applicable to ac3 though.

good to hear about the channel coupling :)

[jruggle]

ok,i will try independent L+R channels.
waiting for the news too!
thanks for your tests.

The only thing of consequence I can find that changed between 0.04 and 0.05 which might be affecting output is, indeed, the stereo rematrixing. I cannot hear any differences though...

However, if I am guessing correctly, the problem might be occuring when exponents are being reused from the previous block, where one of the two blocks uses rematrixing and the other does not. This may lead to some inaccurate exponents, which can sometimes be heard in the output. I've had similar issues come up in the course of the psy-model tests. I believe the newest exponent strategy routine, which has been added since 0.05, would resolve the issue since it uses a least-error method rather than a fixed threshold.

The only thing I can think of as to why 0.04 did not manifest the same problems is that the rematrixing decision algorithm was straight from the spec and probably did not do rematrixing as often. Therefore, the issue may have still been present, but would have been less noticeable.

edit: Did some testing...0.05 and later rematrixing had a bug which chose to do rematrixing WAY too much (95% vs. 17%). I just changed this in SVN so it will be fixed in 0.06 as well.

Then again, I may be wrong about all of this. :)

-Justin

P.S. If all goes as planned, Aften 0.06 will be coming out on 1/28.

[Kurtnoise]

@DarkAvenger : for makefile creation with cmake, I've got this
-- Using YASM/NASM
-- Performing Test HAVE_NASM_VISIBILITY
-- Performing Test HAVE_NASM_VISIBILITY - Failure
What is it exactly ?



And before to release the 0.06, why not fix also these warnings :
[ 61%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_common_init.obj
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c: In function 'sse_mdct_ctx_init':
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM2' may be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:143: warning: 'XMM0' may be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM2' may be used uninitialized in this function
c:/temp/aften/libaften/x86/x86_sse_mdct_common_init.c:169: warning: 'XMM0' may be used uninitialized in this function
[ 66%] Building C object CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.obj
[ 71%] Building ASM object CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.obj
Linking C static library libaften_static.a
[ 71%] Built target aften_static
Scanning dependencies of target aften_wav
[ 76%] Building C object CMakeFiles/aften_wav.dir/aften/wav.obj
Linking C static library libaften_wav.a
[ 76%] Built target aften_wav
Scanning dependencies of target aften_exe
[ 80%] Building C object CMakeFiles/aften_exe.dir/aften/aften.obj
Linking C executable aften.exe
[ 80%] Built target aften_exe
Scanning dependencies of target wavfilter
[ 85%] Building C object CMakeFiles/wavfilter.dir/util/wavfilter.obj
[ 90%] Building C object CMakeFiles/wavfilter.dir/libaften/filter.obj
Linking C executable wavfilter.exe
[ 90%] Built target wavfilter
Scanning dependencies of target wavinfo
[ 95%] Building C object CMakeFiles/wavinfo.dir/util/wavinfo.obj
c:/temp/aften/util/wavinfo.c: In function 'wavinfo_print':
c:/temp/aften/util/wavinfo.c:314: warning: format '%ld' expects type 'long int', but argument 2 has type 'int64_t'
Linking C executable wavinfo.exe
[ 95%] Built target wavinfo
Scanning dependencies of target wavrms
[100%] Building C object CMakeFiles/wavrms.dir/util/wavrms.obj
Linking C executable wavrms.exe
[100%] Built target wavrms

I use gcc 4.1.1 & nasm 0.98

[DarkAvenger]

@DarkAvenger : for makefile creation with cmake, I've got this

What is it exactly ?


Unimportant on Windows, probably I should deactivate that test in Windows. (On linux all symbols are public/visible by default in a shared lib, so I detect whether nasm/yasm can hide them.)



And before to release the 0.06, why not fix also these warnings :


I use gcc 4.1.1 & nasm 0.98

The warnings on mdct are wrong. gcc (nor icc, but there you can deactivate them) is not smart enough.

The last warning in wavinfo was fixed by Justin.


BTW, does anybody have an intel Mac to test compilng aften in MacOS X?

[Kurtnoise]

gcc is not smart enough...funny. :D


btw, thanks for the channels mapping.

[yuvi]

BTW, does anybody have an intel Mac to test compilng aften in MacOS X?

It fails as such with the cmake generated makefile (the Xcode generation fails internally to cmake due to CMAKE_EXE_LINKER_FLAGS not being set during the nasm visibility test):

[ 71%] Building ASM object CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o
/usr/bin/nasm -f elf -I/Users/yuvi/aften/default -I/Users/yuvi/aften -I/Users/yuvi/aften/libaften -I/Users/yuvi/aften/aften -I/Users/yuvi/aften/libaften/x86 -DHAVE_CONFIG_H -DAFTEN_BUILD_LIBRARY -o CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o /Users/yuvi/aften/libaften/x86/x86_cpu_caps_detect.nasm
Linking C static library libaften_static.a
/usr/bin/cmake -P CMakeFiles/aften_static.dir/cmake_clean_target.cmake
/usr/bin/cmake -E cmake_link_script CMakeFiles/aften_static.dir/link.txt --verbose=1
/usr/bin/ar cr libaften_static.a "CMakeFiles/aften_static.dir/libaften/a52enc.o" "CMakeFiles/aften_static.dir/libaften/bitalloc.o" "CMakeFiles/aften_static.dir/libaften/bitio.o" "CMakeFiles/aften_static.dir/libaften/crc.o" "CMakeFiles/aften_static.dir/libaften/dynrng.o" "CMakeFiles/aften_static.dir/libaften/window.o" "CMakeFiles/aften_static.dir/libaften/mdct.o" "CMakeFiles/aften_static.dir/libaften/exponent.o" "CMakeFiles/aften_static.dir/libaften/filter.o" "CMakeFiles/aften_static.dir/libaften/util.o" "CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps.o" "CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_dummy.o" "CMakeFiles/aften_static.dir/libaften/x86/x86_sse_mdct_common_init.o" "CMakeFiles/aften_static.dir/libaften/x86/x86_sse3_mdct_dummy.o" "CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o"
/usr/bin/ranlib libaften_static.a
/usr/bin/cmake -E cmake_progress_report /Users/yuvi/aften/default/CMakeFiles 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

[...]

[ 80%] Building C object CMakeFiles/aften_exe.dir/aften/aften.o
/usr/bin/gcc -Wno-switch -Wextra -Wdeclaration-after-statement -Wbad-function-cast -Wfloat-equal -Wdisabled-optimization -std=gnu99 -pedantic -Wall -Wpointer-arith -Wredundant-decls -Wformat -Wunused -fvisibility=hidden -funroll-loops -fomit-frame-pointer -O3 -DNDEBUG -I/Users/yuvi/aften/default -I/Users/yuvi/aften -I/Users/yuvi/aften/libaften -I/Users/yuvi/aften/aften -I/Users/yuvi/aften/libaften/x86 -DHAVE_CONFIG_H -DAFTEN_BUILD_LIBRARY -o CMakeFiles/aften_exe.dir/aften/aften.o -c /Users/yuvi/aften/aften/aften.c
Linking C executable aften
/usr/bin/cmake -P CMakeFiles/aften_exe.dir/cmake_clean_target.cmake
/usr/bin/gcc -Wno-switch -Wextra -Wdeclaration-after-statement -Wbad-function-cast -Wfloat-equal -Wdisabled-optimization -std=gnu99 -pedantic -Wall -Wpointer-arith -Wredundant-decls -Wformat -Wunused -fvisibility=hidden -funroll-loops -fomit-frame-pointer -O3 -DNDEBUG -headerpad_max_install_names -fPIC "CMakeFiles/aften_exe.dir/aften/aften.o" -o aften -L/Users/yuvi/aften/default -laften_wav -laften_static -lm
/usr/bin/ld: Undefined symbols:
__alDetectx86CPUCaps
collect2: ld returned 1 exit status
make[2]: *** [aften] Error 1
make[1]: *** [CMakeFiles/aften_exe.dir/all] Error 2
make: *** [all] Error 2

The problem is that you're specifying "-f elf" to nasm, where Mac OS X uses Mach-O. I don't know cmake well enough to fix it myself, and unfortunately I won't have access to an Intel Mac again for some time to test further.

[HeadBangeR77]

Sorry to interrupt that developement-compilation discussion with a noob-like question. ;)
Which revision of Aften & its GUI would you recommend? I should add I won't be using DRC at all. And the 2nd one: which container could handle AC3 VBR + XviD/x264?

Hope I didn't bother too much. ;)
<...and he disappeared into thin air>

cheers,
HDBR77

[jruggle]

Sorry to interrupt that developement-compilation discussion with a noob-like question. ;)
Which revision of Aften & its GUI would you recommend? I should add I won't be using DRC at all. And the 2nd one: which container could handle AC3 VBR + XviD/x264?

Hope I didn't bother too much. ;)
<...and he disappeared into thin air>

cheers,
HDBR77

The first answer is easy. The most recent versions. :) My guess is that AftenGUI 1.3 works with the Aften r278 binary on Kurtnoise's website.

As far as a container format, the only one I can get to work using mpeg4 video and vbr ac-3 is Matroska. I imagine EVO (used in HD-DVD) would work since both h.264 and ac-3 are required codecs. I just don't have a muxer to try it out.

-Justin

[DarkAvenger]

@Yuvi

I hopefully fixed it. Thanks for your test. If you are able to test again, I'd be happy to get a confirmation.

[BigDid]

... which container could handle AC3 VBR + XviD/x264?

Hi,

AC3 VBR wil be very difficult to play with common programs and no SAP; better stay with CBR ATM.

AVI handles Xvid and AC3; I often recode Ac3 with DRC; I don't use x264 but I recall reading discussion about MP4 and ac3. If not mistaken it is not compliant but could eventually be done ...

Did

[HeadBangeR77]

AC3 VBR wil be very difficult to play with common programs and no SAP; better stay with CBR ATM.
Thank for the tip - it's as I feared, unfortunatelly (I want to keep AC3 5.1 from time to time, and thought VBR would spare me some bits in favor of video).

AVI handles Xvid and AC3; I often recode Ac3 with DRC; I don't use x264 but I recall reading discussion about MP4 and ac3. If not mistaken it is not compliant but could eventually be done ...

Did
Yep, in AVIs it's fine, at least with AVI-Mux GUI (no problems with AC3 + XviD or x264) - the same is valid for MKV.

Grüße

[BigDid]

Thank for the tip - it's as I feared, unfortunatelly (I want to keep AC3 5.1 from time to time, and thought VBR would spare me some bits in favor of video).
Hi,

You can go from 448 to 384 or 384 to 384 (if you want to add DRC) or even try 384 to 320 (it is AC3 compliant) if you prefer to keep 5.1 over quality :D

Yep, in AVIs it's fine, at least with AVI-Mux GUI (no problems with AC3 + XviD or x264)
I do AVI ac3+Xvid with VDmod without problems.

Did

[yuvi]

@Yuvi

I hopefully fixed it. Thanks for your test. If you are able to test again, I'd be happy to get a confirmation.

It still fails, with the following error:

[ 71%] Building ASM object CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o
/usr/bin/nasm -f macho -I/Users/yuvi/aften/default -I/Users/yuvi/aften -I/Users/yuvi/aften/libaften -I/Users/yuvi/aften/aften -I/Users/yuvi/aften/libaften/x86 -DHAVE_CONFIG_H -DAFTEN_BUILD_LIBRARY -o CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o /Users/yuvi/aften/libaften/x86/x86_cpu_caps_detect.nasm
/Users/yuvi/aften/libaften/x86/x86_cpu_caps_detect.nasm:35: panic: invalid section name .txt
make[2]: *** [CMakeFiles/aften_static.dir/libaften/x86/x86_cpu_caps_detect.o] Error 3
make[1]: *** [CMakeFiles/aften_static.dir/all] Error 2
make: *** [all] Error 2

Changing the section name to .text instead of .txt gets it to compile and work with sse3, though I don't know the difference between the two (I think the nasm shipped with Mac OS X has some weird oddities like that.)

I'll test it more thoroughly when I can, for now I'm working on getting Altivec mdct from http://icculus.org/al_osx/ working with Aften.

[DarkAvenger]

@yuvi

Thanks, I looked into nasm manual and it seems .text is in fact the right name. I changed it now.

[wisodev]

Which revision of Aften & its GUI would you recommend?
cheers,
HDBR77

You can try my little tool called WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html). It is small, fast, open source and easy to use GUI with built-in Aften library. The WAV to AC3 Encoder is distributed under GPL license. Current release version is 0.1. Today I will release version 0.2 with updated Aften library and new options (you can check svn repository (http://thefrontend.svn.sourceforge.net/viewvc/thefrontend/EncWAVtoAC3/) for current development version).

Thanks,
wisodev

[raquete]

thanks for the WAV to AC3 Encoder wisodev.
comments...
i encoded "George Harrison-Beware of Darkness" with AftenGUI 1.2(Aften-0.04 2006-Aug-06) and with Wav to AC3 Encoder.
the result from Wav to AC3 Encoder have more bright,is more natural and cristaline.
the Aften version inside Wav to Ac3 Encoder was done for yourself?
thanks so much and congrats! :)

(i can upload the 2 AC3 files if any "abx user" want to hear the differences.)

[wisodev]

thanks for the WAV to AC3 Encoder wisodev.
comments...
i encoded "George Harrison-Beware of Darkness" with AftenGUI 1.2(Aften-0.04 2006-Aug-06) and with Wav to AC3 Encoder.
the result from Wav to AC3 Encoder have more bright,is more natural and cristaline.
the Aften version inside Wav to Ac3 Encoder was done for yourself?
thanks so much and congrats! :)

(i can upload the 2 AC3 files if any "abx user" want to hear the differences.)

Wav to AC3 Encoder includes Aften from subversion repository (svn) at revision 265 (this is fairly new version) so I think this is the reason why there are quality differences.

[jruggle]

Version 0.06 of Aften is now available.

http://aften.sourceforge.net

Changes since 0.05:

added SSE/SSE3 mdct code (based on vorbis lancer by blacksword8192@hotmail.com)
added runtime SIMD detection code (Prakash Punnoor)
added CMake build system with shared lib/dll support
optional faster bit allocation by reducing accuracy/quality
replaced MDCT code with implementation from libvorbis
added Dynamic Range Compression encoding w/ profile selection
improved exponent strategy decision
accuracy increase in bit allocation
new longhelp option for detailed commandline info


This release is source-only. Future releases will be the same. There are links on the Aften website to theFrontend and AftenGUI, which have been offering periodic binary releases.

Thanks for all your support!

-Justin

[wisodev]

This release is source-only. Future releases will be the same. There are links on the Aften website to theFrontend and AftenGUI, which have been offering periodic binary releases.

Thanks for all your support!

-Justin

I have added Aften version 0.06 binaries to win32builds (https://sourceforge.net/projects/win32builds/) project.

Download binaries: aften-0.06-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.06-bin.zip?download) (1 251 818 bytes) | aften-0.06-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.06-bin.rar?download) (456 094 bytes)
Download sources: aften-0.06-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.06-src.zip?download) (129 175 bytes) | aften-0.06-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.06-src.rar?download) (71 434 bytes)

Latest builds are always available at win32builds homepage (http://win32builds.sourceforge.net/aften/index.html).

Thanks,
wisodev

[DarkAvenger]

@wisodev

You might want to use a compresser which has support for solid archives. As your dll and exe don't differ that much, space savings would be much higher than by using an archiver which compresses files individually (like zip). tar.bz2 is already 0.8MB instead of 1.2MB, rar with solid and otherwise default is 0.45MB, and p7zip <0.4MB...

[wisodev]

@wisodev

You might want to use a compresser which has support for solid archives. As your dll and exe don't differ that much, space savings would be much higher than by using an archiver which compresses files individually (like zip). (An tar.bz2 is alread 0.8MB instead of 1.2MB, an rar with solid and otherwise default is 0.45MB, and p7zip <0.4MB...)

I was using .zip archives because they have best support across windows platform.

But you are right and I will add RAR packages.

Edit: changed from 7-Zip to RAR, because some strange things were happening with sf.net FRS.

[Atak_Snajpera]

Athen 0.06 does not work with BePipe and avs2wav! Old 0.05 version works without problems.

[jruggle]

Athen 0.06 does not work with BePipe and avs2wav! Old 0.05 version works without problems.
Please give more info or someone else please confirm...and give more info. Also, could someone with Windows test to see if pipes work okay on the commandline? They work just fine for me in Linux. There were a lot of changes to the wav reader, but I also did quite a bit of testing. Unfortunately, my test environment is limited to Linux.

-Justin

[tebasuna51]

Confirmed, don't work with bepipe:

bepipe --script "WavSource(^6chan.wav^)" | aften.exe - output.ac3
...
Channels=6, BitsPerSample=16, SampleRate=48000Hz
Writing Header...
Writing Data...
0% invalid wav file: -
Done!

[Mug Funky]

piping doesn't work in foobar either.

it hasn't worked since the DRC build i tested out (i forget which rev that is), but worked with the first 0.05 release.

[wisodev]

I've done few tests (using version 0.06) on my Windows XP machine:
Using batch sript: test.cmd
@echo off

aften "6_Channel_ID.wav" "6_Channel_ID (org).ac3"

aften - "6_Channel_ID inPipe.ac3" < "6_Channel_ID.wav"

aften "6_Channel_ID.wav" - > "6_Channel_ID outPipe.ac3"

aften - - < "6_Channel_ID.wav" > "6_Channel_ID in_outPipe.ac3"

pause

Here are the results:
Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

Signed 16-bit 44100 Hz 6-channel
progress: 100% | q: 486.3 | bw: 39.0 | bitrate: 448.0 kbps

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

Signed 16-bit 44100 Hz 6-channel
progress: 100% | q: 486.3 | bw: 39.0 | bitrate: 448.0 kbps

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

Signed 16-bit 44100 Hz 6-channel
progress: 100% | q: 486.3 | bw: 39.0 | bitrate: 448.0 kbps

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

Signed 16-bit 44100 Hz 6-channel
progress: 100% | q: 486.4 | bw: 39.0 | bitrate: 448.0 kbps


So piping works here.

Input file:
C:\Documents and Settings\wiso\Pulpit\test>wavinfo < 6_Channel_ID.wav

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
File:
Name: [stdin]
File Size: 3089060
Format:
Type: Microsoft PCM
Channels: 6
Sample Rate: 44100 Hz
Avg bytes/sec: 529200
Block Align: 12 bytes
Bit Width: 16
Channel Mask: 0x03F
Data:
Start: 128
Data Size: 3088932
Samples: 257411
Playing Time: 5.84 sec
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[jruggle]

Confirmed, don't work with bepipe:

My first guess is that my wav format tolerance is too strict. Try this patch and see if it accepts the input.

Index: aften/wav.c
===================================================================
--- aften/wav.c (revision 296)
+++ aften/wav.c (working copy)
@@ -138,7 +138,7 @@
wf->filepos += 4;
chunksize = read4le(fp);
wf->filepos += 4;
- if(id == 0 || chunksize == 0) return -1;
+ if(id == 0) return -1;
switch(id) {
case FMT__ID:
if(chunksize < 16) return -1;
@@ -154,10 +154,9 @@
wf->filepos += 4;
wf->block_align = read2le(fp);
wf->filepos += 2;
- if(wf->block_align == 0) return -1;
wf->bit_width = read2le(fp);
+ if(wf->bit_width == 0) return -1;
wf->filepos += 2;
- if(wf->bit_width == 0) return -1;
chunksize -= 16;

// WAVE_FORMAT_EXTENSIBLE data
@@ -174,7 +173,8 @@

if(wf->format == WAVE_FORMAT_PCM || wf->format == WAVE_FORMAT_IEEEFLOAT) {
// override block alignment in header for uncompressed pcm
- wf->block_align = MAX(1, ((wf->bit_width + 7) >> 3) * wf->channels);
+ wf->block_align = ((wf->bit_width + 7) >> 3) * wf->channels;
+ if(wf->block_align == 0) return -1;
}
wf->bytes_per_sec = wf->sample_rate * wf->block_align;

@@ -199,6 +199,9 @@
case DATA_ID:
if(!found_fmt) return -1;
wf->data_size = chunksize;
+ if(wf->data_size == 0) {
+ wf->data_size = UINT32_MAX;
+ }
wf->data_start = wf->filepos;
if(wf->seekable && wf->file_size > 0) {
// limit data size to end-of-file

[tebasuna51]

@jruggle
Not problem with wav header, absolutely standard PCM 16 bit int 48 KHz 6 ch and correct.
ChunkID .....: RIFF
ChunkSize ...: 3840036
Format ......: WAVE
Subchunk1ID .: fmt
Subchunk1Size: 16
AudioFormat .: 1 Integer data.
NumChannels .: 2
SampleRate ..: 48000
ByteRate ....: 192000
BlockAlign ..: 4
BitsPerSample: 16
OffsetData ..: 45
DataLength ..: 3840000
Duration ...: 20 sec., (0h. 0m. 20 s.)

@wisodev
Your test.cmd work here too, but not:
type 2_16ip.wav | aften - output.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

invalid wav file: -
El proceso ha intentado escribir en una canalización que no existe.
Seems work different with '|' and '>' or '<'
(Windows XP sp1, .NET FrameWork v2.0)

With a wavfix tool (C#):
type 2_16ip.wav | wavfix - output.wav
##################################################################
WavFix v1.0.0.1: Fix or create PCM wav header. (Tebasuna 2006)
##################################################################

With 2_16ip.wav and output.wav bit-identical.

[wisodev]

@wisodev
Your test.cmd work here too, but not:
type 2_16ip.wav | aften - output.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

invalid wav file: -
El proceso ha intentado escribir en una canalización que no existe.
Seems work different with '|' and '>' or '<'
(Windows XP sp1, .NET FrameWork v2.0)

With a wavfix tool (C#):
type 2_16ip.wav | wavfix - output.wav
##################################################################
WavFix v1.0.0.1: Fix or create PCM wav header. (Tebasuna 2006)
##################################################################

With 2_16ip.wav and output.wav bit-identical.

Version 0.05 I think didn't set binary mode for input file stream (and output too) as this is standard for *nix OS. Normally in Win32 you set to binary mode input stream and this works with > and <. But 'type' command returns data in text mode so there is a problem. Input is in text mode and Aften reads it as binary data. But I need to test this!

[tebasuna51]

No problem with 'type' and Aften v0.5
type 2_16ip.wav | aften - output.ac3

Aften: A/52 audio encoder
(c) 2006 Justin Ruggles

Signed 16-bit 48000 Hz stereo
progress: 100% | q: 463.5 | bw: 38.0 | bitrate: 192.0 kbps

[wisodev]

No problem with 'type' and Aften v0.5
type 2_16ip.wav | aften - output.ac3

Aften: A/52 audio encoder
(c) 2006 Justin Ruggles

Signed 16-bit 48000 Hz stereo
progress: 100% | q: 463.5 | bw: 38.0 | bitrate: 192.0 kbps

I tested this with version 0.05 (using my build and kurtnoise) and there is the same problem with version 0.06.

I'm running Windows XP SP2 with up to date system updates.
$ type 6_Channel_ID.wav | aften - 6_Channel_ID.ac3

Aften: A/52 audio encoder
(c) 2006 Justin Ruggles

invalid wav file: -
Proces próbował zapisu do nieistniejącego potoku.

[wisodev]

My first guess is that my wav format tolerance is too strict. Try this patch and see if it accepts the input.

Index: aften/wav.c
===================================================================
--- aften/wav.c (revision 296)
+++ aften/wav.c (working copy)
@@ -138,7 +138,7 @@
wf->filepos += 4;
chunksize = read4le(fp);
wf->filepos += 4;
- if(id == 0 || chunksize == 0) return -1;
+ if(id == 0) return -1;
switch(id) {
case FMT__ID:
if(chunksize < 16) return -1;
@@ -154,10 +154,9 @@
wf->filepos += 4;
wf->block_align = read2le(fp);
wf->filepos += 2;
- if(wf->block_align == 0) return -1;
wf->bit_width = read2le(fp);
+ if(wf->bit_width == 0) return -1;
wf->filepos += 2;
- if(wf->bit_width == 0) return -1;
chunksize -= 16;

// WAVE_FORMAT_EXTENSIBLE data
@@ -174,7 +173,8 @@

if(wf->format == WAVE_FORMAT_PCM || wf->format == WAVE_FORMAT_IEEEFLOAT) {
// override block alignment in header for uncompressed pcm
- wf->block_align = MAX(1, ((wf->bit_width + 7) >> 3) * wf->channels);
+ wf->block_align = ((wf->bit_width + 7) >> 3) * wf->channels;
+ if(wf->block_align == 0) return -1;
}
wf->bytes_per_sec = wf->sample_rate * wf->block_align;

@@ -199,6 +199,9 @@
case DATA_ID:
if(!found_fmt) return -1;
wf->data_size = chunksize;
+ if(wf->data_size == 0) {
+ wf->data_size = UINT32_MAX;
+ }
wf->data_start = wf->filepos;
if(wf->seekable && wf->file_size > 0) {
// limit data size to end-of-file


I does not work on my OS with my builds. But the problem is in this function. I think.

[jruggle]

Version 0.05 I think didn't set binary mode for input file stream (and output too) as this is standard for *nix OS. Normally in Win32 you set to binary mode input stream and this works with > and <. But 'type' command returns data in text mode so there is a problem. Input is in text mode and Aften reads it as binary data. But I need to test this!

If the wav headers are okay, this is much more likely to be the culprit. I have a feeling it happened at r112. Before that, binary mode on stdin was set for __MINGW__ and that changed it to _WIN32 to go with the new build system. Not that the change was wrong...but it might provide some clues.

edit: also, I just committed a change to give more specific error messages for wav header parsing, so you might try that to see if it helps pin-point the problem.

[wisodev]

If the wav headers are okay, this is much more likely to be the culprit. I have a feeling it happened at r112. Before that, binary mode on stdin was set for __MINGW__ and that changed it to _WIN32 to go with the new build system. Not that the change was wrong...but it might provide some clues.

edit: also, I just committed a change to give more specific error messages for wav header parsing, so you might try that to see if it helps pin-point the problem.

I tested this wav patch:
$ type 6_Channel_ID.wav | aften - 6_Channel_ID.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

invalid or empty chunk in wav header
invalid wav file: -
Proces próbował zapisu do nieistniejącego potoku.

[jruggle]

I tested this wav patch:
$ type 6_Channel_ID.wav | aften - 6_Channel_ID.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

invalid or empty chunk in wav header
invalid wav file: -
Proces próbował zapisu do nieistniejącego potoku.

Getting closer. Try this.
Index: wav.c
===================================================================
--- wav.c (revision 304)
+++ wav.c (working copy)
@@ -147,8 +147,9 @@
wf->filepos += 4;
chunksize = read4le(fp);
wf->filepos += 4;
- if(id == 0 || chunksize == 0) {
- fprintf(stderr, "invalid or empty chunk in wav header\n");
+ if(chunksize == 0) {
+ fprintf(stderr, "empty '%c%c%c%c' chunk in wav header\n",
+ id&0xFF, (id>>8)&0xFF, (id>>16)&0xFF, (id>>24)&0xFF);
return -1;
}
switch(id) {

[wisodev]

Getting closer. Try this.
Index: wav.c
===================================================================
--- wav.c (revision 304)
+++ wav.c (working copy)
@@ -147,8 +147,9 @@
wf->filepos += 4;
chunksize = read4le(fp);
wf->filepos += 4;
- if(id == 0 || chunksize == 0) {
- fprintf(stderr, "invalid or empty chunk in wav header\n");
+ if(chunksize == 0) {
+ fprintf(stderr, "empty '%c%c%c%c' chunk in wav header\n",
+ id&0xFF, (id>>8)&0xFF, (id>>16)&0xFF, (id>>24)&0xFF);
return -1;
}
switch(id) {


Results:
$ type 6_Channel_ID.wav | aften - 6_Channel_ID.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

empty ' ' chunk in wav header
invalid wav file: -
Proces próbował zapisu do nieistniejącego potoku.


:(

[jruggle]

Results:
$ type 6_Channel_ID.wav | aften - 6_Channel_ID.ac3

Aften: A/52 audio encoder
Version 0.06
(c) 2006-2007 Justin Ruggles, et al.

empty ' ' chunk in wav header
invalid wav file: -
Proces próbował zapisu do nieistniejącego potoku.


:(


whoa...getting weirder. I just wish I could reproduce the problem myself so I could debug without posting back and forth... So I'll just write down my ideas instead.

1) It's obviously reading something right since it passes the RIFF and WAVE tests.

2) You can disable the error for 0-size chunks and print out the hex code for each chunk instead of characters like my last patch.

3) Another thought is to throw in some checks for EOF. The read4le and read2le functions do not check for EOF. One of the consequence of text mode vs. binary mode is interpreting data characters as control characters...such as EOF. So this is a possible suspect.

-Justin

[wisodev]

whoa...getting weirder. I just wish I could reproduce the problem myself so I could debug without posting back and forth... So I'll just write down my ideas instead.

1) It's obviously reading something right since it passes the RIFF and WAVE tests.

2) You can disable the error for 0-size chunks and print out the hex code for each chunk instead of characters like my last patch.

3) Another thought is to throw in some checks for EOF. The read4le and read2le functions do not check for EOF. One of the consequence of text mode vs. binary mode is interpreting data characters as control characters...such as EOF. So this is a possible suspect.

-Justin

I will try later today to debug wav.c using yours ideas.

[wisodev]

Uff, the problem was with:

wf->seekable = !fseek(fp, 0, SEEK_END);


So I added simple check:

/* no seeking for pipes under windows os */
#ifdef _WIN32
if(fp != stdin)
wf->seekable = !fseek(fp, 0, SEEK_END);
#else
wf->seekable = !fseek(fp, 0, SEEK_END);
#endif


Now the output is the same as for normal file input.

Patch for svn revision 304:

Index: aften/wav.c
===================================================================
--- aften/wav.c (revision 304)
+++ aften/wav.c (working copy)
@@ -39,6 +39,8 @@
read4le(FILE *fp)
{
uint32_t x;
+ if(feof(fp))
+ return 0;
fread(&x, 4, 1, fp);
return le2me_32(x);
}
@@ -47,6 +49,8 @@
read2le(FILE *fp)
{
uint16_t x;
+ if(feof(fp))
+ return 0;
fread(&x, 2, 1, fp);
return le2me_16(x);
}
@@ -112,7 +116,14 @@

/* attempt to get file size */
wf->file_size = 0;
+
+ /* no seeking support for pipes */
+#ifdef _WIN32
+ if(fp != stdin)
+ wf->seekable = !fseek(fp, 0, SEEK_END);
+#else
wf->seekable = !fseek(fp, 0, SEEK_END);
+#endif
if(wf->seekable) {
// TODO: portable 64-bit ftell
long fs = ftell(fp);
@@ -147,9 +158,10 @@
wf->filepos += 4;
chunksize = read4le(fp);
wf->filepos += 4;
- if(id == 0 || chunksize == 0) {
- fprintf(stderr, "invalid or empty chunk in wav header\n");
- return -1;
+ if(chunksize == 0) {
+ fprintf(stderr, "empty '%08X' chunk in wav header\n",
+ id);
+ return -1;
}
switch(id) {
case FMT__ID:


Justin if you put this patch into repository I will release new binaries package.

Note: added patched binary (exe_org build) for testing.

Thanks,
wisodev

Edit: removed attachment and added binaries to my website, see post #437

[Boulder]

Could you add the binary to your website, please? I don't know if the mods come around here to approve the attachments too often.

[Kurtnoise]

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev304%2B.zip

[Boulder]

Thanks :)

EDIT: (Are you going to supply a new AftenGUI sometime? When I feed a mono WAV file in it and try to encode at 1.0ch, nothing happens, there's no AC3 file produced.) Just noticed that if the LFE Low-Pass Filter is enabled, it doesn't work. Otherwise no problems.

[Atak_Snajpera]

Finally Aften is working again with Bepipe ... Thanks

[wisodev]

Could you add the binary to your website, please? I don't know if the mods come around here to approve the attachments too often.

Binaries:
aften-0.06-bin-pipes-patch.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.06-bin-pipes-patch.rar?download)

Sources:
aften-0.06-src-pipes-patch.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.06-src-pipes-patch.rar?download)

[jruggle]

Thanks wisodev. I applied the change to svn.

On an unrelated note, the changes DarkAvenger and I have in store should keep Aften SVN in a state of constant change...for a little while at least. :)

-Justin

[wisodev]

Thanks wisodev. I applied the change to svn.

On an unrelated note, the changes DarkAvenger and I have in store should keep Aften SVN in a state of constant change...for a little while at least. :)

-Justin

No problem.

I'm subscribed to Aften mailing lists and I'm up to date with Aften current development progress. When I'll see that the current development version is ready to release binaries I will do it.

Thanks,
wisodev

[Kurtnoise]

Are you going to supply a new AftenGUI sometime?
Maybe...

When I feed a mono WAV file in it and try to encode at 1.0ch, nothing happens, there's no AC3 file produced.
Does it work directly with the command line ?

Just noticed that if the LFE Low-Pass Filter is enabled, it doesn't work.
I'll check this.

[Boulder]

What I meant was that when a mono file is fed and LFE Low-Pass Filter is enabled, nothing happens. I just tried the command line and it says that lfe filter cannot be used as there is no lfe channel (which obviously is true;))

So you probably need a check for that, maybe even grey out incompatible/useless options when a certain channel configuration is selected? Otherwise the GUI has worked just fine :)

[wisodev]

I have released version 0.2 of WAV to AC3 Encoder. Now using latest Aften release at version 0.06 by Justin Ruggles.

Program website:
http://www.thefrontend.net/EncWAVtoAC3/index.html

Binary Package (Win32 and Win64):
EncWAVtoAC3-0.2-bin.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.2-bin.zip?download)

Installer Package (Win32 and Win64):
EncWAVtoAC3-0.2-installer.exe (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.2-installer.exe?download)

Source Package (VC++ 2005):
EncWAVtoAC3-0.2-src.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.2-src.zip?download)

Changelog:

Version 0.2:
- added all aften settings
- many GUI improvements
- added presets (load, save, add, delete)
- added output path
- loading last presets from EncWAVtoAC3.cfg file
- added two default presets
- updated to Aften 0.06 sources
- added new icon


Thanks,
wisodev

[raquete]

- loading last presets from EncWAVtoAC3.cfg file the quality preset back to zero(Auto) after close and open EncWAVtoAC3 again.
edit:no problems,was only needed adjust and save the desired preset!

...and thank you so much for the new version wisodev,
is very cool. :)

[wisodev]

the quality preset back to zero(Auto) after close and open EncWAVtoAC3 again.
edit:no problems,was only needed adjust and save the desired preset!

...and thank you so much for the new version wisodev,
is very cool. :)

Oh one bug for start is not so bad, I fixed this and added sources to svn repository. I will release binaries later today, when I will finish some new things.

Thanks,
wisodev

[wisodev]

I have released version 0.3 of WAV to AC3 Encoder.

Program website:
http://www.thefrontend.net/EncWAVtoAC3/index.html

Binary Package (Win32 and Win64):
EncWAVtoAC3-0.3-bin.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.3-bin.zip?download)

Installer Package (Win32 and Win64):
EncWAVtoAC3-0.3-installer.exe (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.3-installer.exe?download)

Source Package (VC++ 2005):
EncWAVtoAC3-0.3-src.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.3-src.zip?download)

Changelog:

Version 0.3:
- added main menu
- added About dialog box
- added Generate bath file to generate command-line batch file
- fixed bitrate/quality slider not restored after reopening program
- added output path label
- removed two presets (done already in 0.2 but not updated Changelog)


Thanks,
wisodev

[raquete]

today soon version 0.2 was very cool,now the version 0.3 is fantastic.
thank you again wisodev.

[HeadBangeR77]

@ wisodev
Good job! Thanks very much, mate. :)

[Kurtnoise]

Small typos in the last CMakeLists.txt ???

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 354)
+++ CMakeLists.txt (working copy)
@@ -221,7 +221,7 @@
ADD_LIBRARY(aften_static STATIC ${LIBAFTEN_SRCS})
#SET_TARGET_PROPERTIES(aften_static PROPERTIES OUTPUT_NAME aften)
SET_TARGET_PROPERTIES(aften_static PROPERTIES LINKER_LANGUAGE C)
-SET_PROPERTIES(TARGET aften_static PROPERTIES COMPILE_FLAGS -DAFTEN_BUILD_LIBRARY)
+SET_TARGET_PROPERTIES(aften_static PROPERTIES COMPILE_FLAGS -DAFTEN_BUILD_LIBRARY)
TARGET_LINK_LIBRARIES(aften_static ${LIBM})

# building a static lib to prevent recompilation of wav.c
@@ -232,7 +232,7 @@
SET_TARGET_PROPERTIES(aften_exe PROPERTIES LINKER_LANGUAGE C)
IF(WIN32)
# When linking to static aften, dllimport mustn't be used
- SET_PROPERTIES(TARGET aften_exe PROPERTIES COMPILE_FLAGS -DAFTEN_BUILD_LIBRARY)
+SET_TARGET_PROPERTIES(aften_exe PROPERTIES COMPILE_FLAGS -DAFTEN_BUILD_LIBRARY)
ENDIF(WIN32)
TARGET_LINK_LIBRARIES(aften_exe aften_wav aften_static)

[DarkAvenger]

Nope, its equivalent (but could depend on cmake version?)

[Kurtnoise]

Maybe...I used the last cvs version.

[shae]

Using Kurtnoise's compile of 0.06 (2/2/2006, the directory in the ZIP is called rev304+, the EXE just says "Version SVN"), I found a potential problem.

The number of samples I encoded was an exact multiple of the AC3 frame (1536), but the output AC3 had one extra frame.

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).

[jruggle]

Using Kurtnoise's compile of 0.06 (2/2/2006, the directory in the ZIP is called rev304+, the EXE just says "Version SVN"), I found a potential problem.

The number of samples I encoded was an exact multiple of the AC3 frame (1536), but the output AC3 had one extra frame.

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).

It should only be silence (with only small disturbances) at the beginning and end. The silence at the beginning is due to the fact that each input sample is supposed to be represented in 2 consecutive AC3 frames. If this is not done, the audio will not be encoded accurately. The FFmpeg encoder does this as well, and I made a decision to keep it this way. The extra samples at the end are due to the offset at the beginning, which makes the total samples *not* a multiple of 1536 and creates the need for an extra frame, padded with silence.

I was going to reference the aften-devel mailing list archives, but Sourceforge is giving me a server error... so if it ever comes back up, the thread started on 1/14/07 and was titled "samples flushing".

-Justin

[shae]

Can you elaborate on "each sample is supposed to be represented in 2 consecutive frames"? I don't get it. I thought AC3 frames are independent.

What I'm trying to do is local editing of frames in an AC3 stream. After the edit I need the reencode to be positioned accurately so that I can replace only the modified frames. For now I'm just adding 1280 samples at the beginning and ignoring the first and last output frames, but this adds more steps.

While at it... are there any things I should set correctly in order to have the new encoded frames blend in alright (besides bitrate and channel configuration)? Is there a tool that can show the BSI flags, for example? Is there anything else that I should consider?

BTW: Isn't Aften setting the lowpass too agressively? I will have to check again, but I think for 5.1/384kbit it was 14kHz (or maybe 16kHz). The source AC3 has it at 17-18kHz.

[tebasuna51]

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).
Is not a bug, result from a dialog between Justin and DarkAvenger in Mailing List (http://sourceforge.net/projects/aften) -> aften-devel -> Topic: samples flushing, between 2007-1-14 and 2007-1-19

All the encoders I know (SoftEncode, Scenarist, ac3enc.dll, aften) make a delay of 256 samples (5.333... ms at 48 KHz). Seems an ac3 requirement. Then, instead cut the last 256 samples (like do SoftEncode and Scenarist), aften include a last frame with the last 256 samples and silence.

Edit: I don't see the Justin answer before.

[jruggle]

Can you elaborate on "each sample is supposed to be represented in 2 consecutive frames"? I don't get it. I thought AC3 frames are independent.
In their encoded state, which is in the frequency domain, each frame is independent, but when decoded into the time domain, the blocks of audio samples are overlapped and added to get the final pcm output. This is a result of the (I)MDCT (http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform) [wikipedia].


What I'm trying to do is local editing of frames in an AC3 stream. After the edit I need the reencode to be positioned accurately so that I can replace only the modified frames. For now I'm just adding 1280 samples at the beginning and ignoring the first and last output frames, but this adds more steps.
Just to be helpful, I've added an option to the commandline to remove the start-of-stream padding. I just committed it to SVN about an hour or so ago. The command option is "-pad 0".


While at it... are there any things I should set correctly in order to have the new encoded frames blend in alright (besides bitrate and channel configuration)? Is there a tool that can show the BSI flags, for example? Is there anything else that I should consider?
You should consider the dialnorm setting, which is usually constant in a single "program" stream (i.e. can switch values if going to/from commercials, etc...). I don't know if there is a tool to view the AC3 frame info other than the one I made for my own use. It will be incorporated into Aften eventually.


BTW: Isn't Aften setting the lowpass too agressively? I will have to check again, but I think for 5.1/384kbit it was 14kHz (or maybe 16kHz). The source AC3 has it at 17-18kHz.
It is a tad aggressive, yes, but you can change it. The default values will likely change before the next release anyway. For now, you can use "-w 39" to get about a 17.8 kHz cutoff w/ 48kHz source audio.

[Boulder]

Something I've wondered: should one use any low- or high-pass filters or are they disabled by default because it's recommended not to use them in general?

[foxyshadis]

Lowpass mostly depends on your speakers and your hearing. If you can't hear above 16 or 18k anyway, there's no point in encoding anything above it. (100Hz-10kHz is the most important.) And usually there's quite a bit of information there, so raising the lowpass will leave lower frequencies spread across less bits, so more distorted if it's not high enough. If the source is already low-passed, as most are, it's not such a big deal unless you want to lower it further.

Highpass is only useful if you have a lot of low rumble that you need to get rid of, like phonograph recordings, so it doesn't rattle your neighbors' windows.

Um, it wasn't us who turned it up, no sir off'cer...

[jruggle]

Something I've wondered: should one use any low- or high-pass filters or are they disabled by default because it's recommended not to use them in general?
All of the input filters are recommended by the specification and/or Dolby. But since the effect on quality is not very large, and the speed cost is huge, they are not enabled by default.

[chros]

Can I use the new aften.exe with an avisynth script, how? (so no need for the intermediate wav file)

I tried, but no success ...
Thanks

[DarkAvenger]

I guess using the dll would be better.

[BigDid]

Or via Soundout 0.98 from Sh0dan, which has ac3 output and uses aften:
http://forum.doom9.org/showthread.php?t=120025

Did

[chros]

Thanks, I'll look into it ...

[LigH]

Where is kurtnoise?

http://kurtnoise.free.fr/ is not available (anymore | at the moment?).

[BigDid]

Where is kurtnoise?

http://kurtnoise.free.fr/ is not available (anymore | at the moment?).
Well,

His last post on doom9 was on 2/15 and on french forum unite-video a few hours ago. The Free page is also/still unavailable.

Did

[HeadBangeR77]

His repository page is up again, including Aften rev.382 from today - looks like he's been busy doing a lot of good work for audio community. ;)

[raquete]

including Aften rev.382 from todaythanks to show the news.
looks like he's been busy doing a lot of good work for audio community.really. :)

[wisodev]

I have released version 0.4 of WAV to AC3 Encoder.

Program website:
http://www.thefrontend.net/EncWAVtoAC3/index.html

Binary Package (Win32 and Win64):
EncWAVtoAC3-0.4-bin.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-bin.zip?download) | EncWAVtoAC3-0.4-bin.rar (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-bin.rar?download)

Installer Package (Win32 and Win64):
EncWAVtoAC3-0.4-installer.exe (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-installer.exe?download)

Source Package (VC++ 2005):
EncWAVtoAC3-0.4-src.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-src.zip?download) | EncWAVtoAC3-0.4-src.rar (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-src.rar?download)

Changelog:

Version 0.4:
- added to status bar 'Encoded # files in #'
- changed presets configuration file extension from *.cfg to *.presets
- added program configuration file with extension *.cfg
- added load/save configuration of last main dialog position
- added load/save configuration of all lists column sizes
- added load/save of currently selected preset
- added grid lines to file list and settings list
- added status bar
- added encoding time information to status bar
- added resizing to main dialog
- added drag & drop for files and directories
- added support for Windows 98 SE using Ansi builds


Thanks,
wisodev

Note: I'll update website later because Project Shell Service at sf.net is down.

[shae]

Just to be helpful, I've added an option to the commandline to remove the start-of-stream padding.
Thanks. I think Kurtnoise compiled it by now, but maybe, nevertheless, I should get an SVN client already. :)

In their encoded state, which is in the frequency domain, each frame is independent, but when decoded into the time domain, the blocks of audio samples are overlapped and added to get the final pcm output.
Is this some sort of "deblocking"? And does it mean that each frame in fact encodes 1536+256 samples? Is the mixing a simple (a+b)/2 for each of the 256 samples, or something more elaborate?

I read the SF thread but I'm not clear on why this 256 sample delay is needed. Sure, the very beginning would not be true to the source, but it would be practically unnoticeable. I think cases in which these 256 samples are important are rarer than those in which accurate length or positioning is important.

How about having "-pad 0" the default and allow the opposite override?

You should consider the dialnorm setting, which is usually constant in a single "program" stream (i.e. can switch values if going to/from commercials, etc...).
Since I'm replacing frames in-place, and reencoding a few untouched frames before the changed area then chopping them off, I suppose the overlapped samples would stitch ok, right?

Do you have an estimate on when your AC3 info tool will be released, standalone or as part of Aften? If it'll take a while, perhaps I'd write a simple one in the meantime.

For now, you can use "-w 39" to get about a 17.8 kHz cutoff w/ 48kHz source audio.
Not (22khz * w / 60)?

[BigDid]

His repository page is up again, including Aften rev.382 from today - looks like he's been busy doing a lot of good work for audio community. ;)
Yep,

And I believe this rev is MT friendly :)

Thanks Kurtnoise

Did

[jruggle]

Thanks. I think Kurtnoise compiled it by now, but maybe, nevertheless, I should get an SVN client already. :)


Is this some sort of "deblocking"? And does it mean that each frame in fact encodes 1536+256 samples? Is the mixing a simple (a+b)/2 for each of the 256 samples, or something more elaborate?

It's not deblocking, but part of the MDCT mathematics which is called time-domain alias cancellation. And yes, it sort of does encode 1536+256, or rather, it requires the previous 256 samples to 'accurately' encode the 1st of the 6 blocks. In Aften, we assume that the 256 samples prior to the start of the stream are silent. This ensures that the audio we actually want to encode is represented accurately. The downside is the delay.


I read the SF thread but I'm not clear on why this 256 sample delay is needed. Sure, the very beginning would not be true to the source, but it would be practically unnoticeable. I think cases in which these 256 samples are important are rarer than those in which accurate length or positioning is important.

How about having "-pad 0" the default and allow the opposite override?

"practically unnoticeable" yes, but as including the silent delay samples is standard practice for AC-3 encoders, I would prefer to keep that the default.


Since I'm replacing frames in-place, and reencoding a few untouched frames before the changed area then chopping them off, I suppose the overlapped samples would stitch ok, right?

They would stitch ok, yes. 1 previous frame is enough.


Do you have an estimate on when your AC3 info tool will be released, standalone or as part of Aften? If it'll take a while, perhaps I'd write a simple one in the meantime.

Not too far in the future. It's parsing perfectly right now. It just doesn't output anything. :) I'm trying to decide on a good format for the output.

Not (22khz * w / 60)?
No, sorry this is so confusing. I do want to eventually change this option to use Hz instead. See 'aften -longhelp' for details on how to set the bandwidth.

[shae]

Not too far in the future. It's parsing perfectly right now. It just doesn't output anything. :) I'm trying to decide on a good format for the output.For now, I found out azid.exe can show some info even if not all, and only for the beginning frames (I assume). But that was enough to give me the dialnorm value, which I realized I needed.

As for output format... just a semi-cryptic compact form for each frame, then let GUIs handle it. Optionally, allow selecting which fields to display, and what frame range. Maybe also with some stats for the whole stream.

No, sorry this is so confusing. I do want to eventually change this option to use Hz instead. See 'aften -longhelp' for details on how to set the bandwidth.Since it's w*3+73, it appears the range is 60. And there are 256 bins. Isn't each of fixed bandwidth? (I was wrong in using 22khz above instead of 24, though).

[jruggle]

Since it's w*3+73, it appears the range is 60. And there are 256 bins. Isn't each of fixed bandwidth? (I was wrong in using 22khz above instead of 24, though).

Yes, each bin is of fixed bandwidth, but the minimum bandwidth is 73/256 of 1/2 sample rate. If you're dealing exclusively with 48kHz audio, the formula can be simplified as:
cutoff = (w * 281.25) + 6843.75
or the inverse if you know the cutoff and need the bandwidth code:
w = (cutoff - 6843.75) / 281.25

[newhaven]

hi,
i have a WAV that i encoded using VI in plogue that is 1 hour and 21 minutes in length. after i add the file and enocde in aften 0.6 the encoded ac3 file is only 20 minutes in length. can anybody point me in the correct direction?

thanks --newhaven

[DarkAvenger]

wavinfo source file?

[newhaven]

dark avenger,

sorry, as you can tell i am a newbie. what are you referring to when you ask waveinfo file. the wave i encoded with VI and plogue was a 32 bit 6 channel wave, and this is what i tried encoding in aften. i'm assuming o missed a step somewhere. thanks--newhaven

[DarkAvenger]

Well, if your aften package contains the wavinfo tool, it would be nice if you applied it on your source file to get assured aften detects the wave file correctly.

[HeadBangeR77]

Hello,
Every Afteen package comes with wavfilter.exe, wavinfo.exe, wavrms.exe. I don't know the commandline, but the one mentioned above shall give you some information on your source wav file.

cheers,
HDBR77

Ooops, I was late a bit. :p

[newhaven]

hello again,

despite alo tof searching, i cannot find any info, on how to use the utilities included in aften. can someone please post an explanation/link/anything.

thanks--newhaven

[HeadBangeR77]

You can always copy the whole path to the file (wavinfo) into the windows command line, with a parameter /help or -help (just guessing, works in most cases). ;)

[tebasuna51]

@newhaven
If you have a 1 hour and 21 minutes (4860 seconds), 32 bit (4 bytes) 6 channel wav and samplerate 48 KHz the wav size must be:
4860 * 4 * 6 * 48000 = 5598720000 bytes = 5.21 GB

If your wav have 5.21 GB is a Aften problem, but if your wav file is only 1.21 GB you have only 19 minutes, Aften work OK and your problem is in precedent steps.

[newhaven]

tebasuna,

the wave is 5.25 GB (5,637,574,776 bytes), so is this an aften problem?

i followed ursatmls directions from this post:http://forum.doom9.org/showthread.php?s=&threadid=83844 to create the wave.

any more suggestions?------newhaven

[tebasuna51]

the wave is 5.25 GB (5,637,574,776 bytes), so is this an aften problem?

Seems you have a buggy Aften version, is a typical problem with wav files > 4 GB ( two field in wav header have a overflow and only show 5.25 - 4 = 1.25 -> 20 minutes).

For instance, the -ignorelength parameter in NeroAacEnc permit ignore this two fields and continue encoding until the real end-of-file is reached. Other versions of Aften make the same (not needed any special parameter).

[newhaven]

strange,

when i used plogue to create the 32 bit wave file, i also split each channel into 6 seperate files. i have taken the 6 channels and used surcodes DTS program. the clock in surcode shows 1:21:33.72.
yet when i add the single 6 channel wave file into belight 0.22 rc1 the description is the following:

WAV-mutichannel-9216kbps-48000khz-00:19:25

regards-newhaven

[newhaven]

tebasuna,

i downloaded aften from kurtnoises site. to tell you the honest truth, i have had the same issue with every version of aften i have tried (please don't take this as an insult, i know alot of hard work has gone into this program, who knows, maybe it is something on my pc's end). the encWAV to ac3-0.4 program give me the same result. is there a way to rewrite the WAV header so aften will encode it properly, or is this somehting that must be taken care of by aften?

thanks----newhaven

[tebasuna51]

i downloaded aften from kurtnoises site. to tell you the honest truth, i have had the same issue with every version of aften i have tried (please don't take this as an insult, i know alot of hard work has gone into this program, who knows, maybe it is something on my pc's end).
Don't worry, isn't your PC, seems the 0.06 version have a regression with this issue, at least rev304 and rev432 from kurtnoise site don't work properly.

the encWAV to ac3-0.4 program give me the same result.
Yes is in Aften.exe the problem not with the GUI.
is there a way to rewrite the WAV header so aften will encode it properly, or is this somehting that must be taken care of by aften?
The header can't support wav > 4 GB because the fields to support the length (file and data) have only 4 bytes and 2^32 is the limit.
Old versions of aften work fine. If you don't need drc support (-dynrng #) you can use v0.05 from Kurtnoise site.

[tebasuna51]

This is the wavinfo output with a wav > 4GB
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
File:
Name: z.wav
File Size: unknown
Format:
Type: Microsoft PCM
Channels: 6
Sample Rate: 48000 Hz
Avg bytes/sec: 576000
Block Align: 12 bytes
Bit Width: 16
Channel Mask: 0x03F
Data:
Start: 44
Data Size: 224522240
[ warning! unable to verify true data size ]
Samples: 18710186
Playing Time: 389.80 sec
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The header have the fields:
LeeWavBi 1.0 analyzing file with 4519489580 bytes:
G:\z.wav
----------------------------------------------------------------------
ChunkID .....: RIFF
ChunkSize ...: 224522276 Error: Must be FileLength - 8 = 4519489572
Format ......: WAVE
Subchunk1ID .: fmt
Subchunk1Size: 16
AudioFormat .: 1 Integer data.
NumChannels .: 6
SampleRate ..: 48000
ByteRate ....: 576000
BlockAlign ..: 12
BitsPerSample: 16
OffsetData ..: 45
DataLength ..: 224522240 Warning: we assume Datalength = 4519489536
Duration ...: 7846.336 sec., (2h. 10m. 46.336 s.)
----------------------------------------------------------------------
Like you can see the fields ChunkSize and DataLength (4 bytes each) can't support the real values > 2^32. If we assume:
DataLength = FileSize - OffsetData +1
we obtain the correct duration.

Only if there are subchunks after the Data chunk (possible but not probable) these subchunks are treated as data.

[wisodev]

I have added AFTEN SVN R433 Win32 and Win64 binary and source packages to my website (http://win32builds.sourceforge.net/aften/index.html). This release includes PGO & IPO optimized builds with MMX, SSE, SSE2 and SSE3 assembly optimizations for Win32 (x86) and Win64 (AMD64). Also MT builds are available with parallelization enabled.

Download binaries Win32:
aften-svn-r433-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win32-bin.zip?download) (2 614 835 bytes)
aften-svn-r433-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win32-bin.rar?download) (499 826 bytes)
Download binaries Win64:
aften-svn-r433-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win64-bin.zip?download) (870 848 bytes)
aften-svn-r433-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win64-bin.rar?download) (312 954 bytes)
Download sources:
aften-svn-r433-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-src.zip?download) (157 390 bytes)
aften-svn-r433-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-src.rar?download) (83 638 bytes)

Thanks,
wisodev

[tebasuna51]

r433 don't work with wav files > 4 GB.

[jruggle]

Don't worry, isn't your PC, seems the 0.06 version have a regression with this issue, at least rev304 and rev432 from kurtnoise site don't work properly.


Yes is in Aften.exe the problem not with the GUI.

The header can't support wav > 4 GB because the fields to support the length (file and data) have only 4 bytes and 2^32 is the limit.
Old versions of aften work fine. If you don't need drc support (-dynrng #) you can use v0.05 from Kurtnoise site.

Plain and simple...the wav file is invalid. This is a limitation of the wav format. Some programs out there will go ahead and read the file anyway and just make assumptions about the data size, ignoring the header. I prefer not to do this, as it is technically wrong.

However, I will look into temporarily putting in a commandline option to override the data size specified in the wav header so that these large files can be used.

edit: I added a "-datasize" option to current SVN for user override of data size, in bytes. It is untested at this point, so I'm not sure if it works 100% correctly yet.

[tebasuna51]

Plain and simple...the wav file is invalid. This is a limitation of the wav format. Some programs out there will go ahead and read the file anyway and just make assumptions about the data size, ignoring the header. I prefer not to do this, as it is technically wrong.
The wav file isn't invalid, only two header fields are invalid, not necessaries if we assume the Data subchunk is the last.

This kind of 'invalid' wav's are generated by habitual decoders (azid, faad, foobar-convert, AviSynth-style, ...).

'Some programs' like NeroAacEnc assume this undesired, but real, situation with the parameter -ignorelength, used by default by GUI's like BeHappy, MEGUI, ...

If we use 32 bit precision a 63 minutes multichannel wav file become unsupported by Aften. We can't use 32 bit to encode all movie audio tracks.
We can't use at all (16 bit precision) Aften to encode movie tracks long than 125 minutes.

However, I will look into temporarily putting in a commandline option to override the data size specified in the wav header so that these large files can be used.

edit: I added a "-datasize" option to current SVN for user override of data size, in bytes. It is untested at this point, so I'm not sure if it works 100% correctly yet.
The end user can't know the datasize.
Is more simple than that:

1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.

[raquete]

@ wisodev
no new EncWavtoAC3 version? you have gratefull user here!:)

[wisodev]

@ wisodev
no new EncWavtoAC3 version? you have gratefull user here!:)

I was working on Aften command-line builds and with this come dll builds of libaften.dll. I have added MMX,SSE,SSE2,SSE3 and MT optimized builds. Now I want to integrate this dll builds with WAV to AC3 Encoder to enable switching between different optimized builds witch best suites your hardware. Actually the new version witch will have number 0.5 has already some new things checked in subversion:

Current SVN changelog:
- added more detailed progress status for MT encoding in work dialog
- added option to select number of work threads for MT (number of threads is limited only with your hardware)
- added multi-threading support (two or more files can be encoded in separate threads at the same time)
- changed calculation of total progress in work dialog to more precise
- added elapsed time for current file progress and total progress in encoding dialog
- added filter for .wav files only when adding directory
- added context menu to file list
- fixed bug when user clicked encode button and there where no file in list
then the second time you clicked the encoding process did not start

You can browse sources online: https://svn.sourceforge.net/svnroot/thefrontend/EncWAVtoAC3/

I will be working on dll integration today so version 0.5 will be released very soon (of course if I do not run into some troubles ;-) and I need to add some sort of selection between Aften multi-threading and my version of multi-threading.

[jruggle]

'Some programs' like NeroAacEnc assume this undesired, but real, situation with the parameter -ignorelength, used by default by GUI's like BeHappy, MEGUI, ...

Ok. So would it be better if I added a similar option to Aften to always read data until the end-of-file?

[tebasuna51]

Ok. So would it be better if I added a similar option to Aften to always read data until the end-of-file?
My preferred solution is:
1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.
But I can accept anything ;)

[jruggle]

1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.

Well, I can probably partially accommodate this. What I don't want to do is make it the default behavior to break the standard. So rather than a "trust data size" parameter, I prefer an "ignore data size" parameter, which could also be interpreted as a "read data until EOF" parameter. Also, I don't want to treat streaming input or large input any differently.

What I really need to do is to bite the bullet and try to implement a cross-platform way of getting 64-bit file size. Currently, Aften has different behavior on different systems. If the system is 32-bit, it can only detect IF the file size is over 2 GB because ftell returns an error. If the system is 64-bit, ftell does not return an error...AFAIK...because it returns a long, which would be large enough to hold the file size. Anyway..there are weird Windows issues to solve as well.

I can go ahead and add the option to read data until EOF...but it may not give accurate progress percentage during encoding until I get the file size stuff worked out. I'm not sure what to name the parameter though. I'm thinking something along the lines of "-readtoeof" or "-datatoeof" or "-ignoredatasize" or "-ignoreinputsize". I'm also open to suggestions...but lowercase only and the-shorter-the-better.

[tebasuna51]

"-readtoeof" is ok for me.

Thanks Justin.

[newhaven]

jruggle,

thank you for your willingness to accomodate. as far as naming this, your the creator, abbreviate it and maybe put a note on a read me in the install.


newhaven

[jruggle]

"-readtoeof" is ok for me.

Thanks Justin.

Good. That's what I chose. :) rev 435 removes the "datasize" option and adds "readtoeof". Keeping consistancy with other Aften syntax, you have to do "-readtoeof 1".

edit: note that the progress percentage will stop at 100% after the header data size is reached, but if this option is turned on, encoding will continue...it will just stay at 100% until encoding is done.

[Kurtnoise]

@wisodev: could you compile the last svn revision please ? I would like to compare something with my build...

Thank you.

[tebasuna51]

@wisodev: and can you explain, please, the differences between all the aften.exe options?

[wisodev]

@wisodev: could you compile the last svn revision please ? I would like to compare something with my build...

Thank you.

Yes, revision 449 uploaded: http://win32builds.sourceforge.net/aften/index.html

@wisodev: and can you explain, please, the differences between all the aften.exe options?

Quote from my binaries package readme.txt:
Binaries description (using ICL 9.1 compiler):

Win32 Builds

.\exe_pgo\aften.exe - x86 ICL PGO Build
.\exe_pgo_mmx\aften.exe - x86 ICL PGO MMX Build
.\exe_pgo_mmx_MT\aften.exe - x86 ICL PGO MMX Build with Parallelization
.\exe_pgo_sse\aften.exe - x86 ICL PGO SSE Build
.\exe_pgo_sse_MT\aften.exe - x86 ICL PGO SSE Build with Parallelization
.\exe_pgo_sse2\aften.exe - x86 ICL PGO SSE2 Build
.\exe_pgo_sse2_MT\aften.exe - x86 ICL PGO SSE2 Build with Parallelization
.\exe_pgo_sse3\aften.exe - x86 ICL PGO SSE3 Build
.\exe_pgo_sse3_MT\aften.exe - x86 ICL PGO SSE3 Build with Parallelization

Win64 Builds

.\exe_pgo_x64\aften.exe - AMD64 ICL PGO SSE3 Build
.\exe_pgo_x64_MT\aften.exe - AMD64 ICL PGO SSE3 Build with Parallelization

Glossary:

PGO - Profile-Guided Optimizations by Intel C++ Compiler (http://www.intel.com/)
IPO - Interprocedural Optimization by Intel C++ Compiler (http://www.intel.com/)
MMX - Assembly Opimizations for MMX (http://en.wikipedia.org/wiki/MMX)
SSE - Assembly Opimizations for SSE (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions)
SSE2 - Assembly Opimizations for SSE2 (http://en.wikipedia.org/wiki/SSE2)
SSE3 - Assembly Opimizations for SSE2 (http://en.wikipedia.org/wiki/SSE3)
x86 - Binaries for 32-bit microprocessor architecture (http://en.wikipedia.org/wiki/X86), and
used under Miscorsoft Windows 32 bit operating systems.
AMD64 - Binaries for 64-bit microprocessor architecture (http://en.wikipedia.org/wiki/AMD64),
used under Miscorsoft Windows 64 bit operating systems.

Find more about Intel C++ Compiler: http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cwin/279578.htm

Notes:

Win32 builds will run under Win64 operating systems but Win64 will not run under Win32 OS's.
MMX, SSE, SSE2 and SSE3 builds require compatible CPU's. Use http://www.cpuid.com/cpuz.php
program to check if your hardware is compatible with specific build.

SSE3 builds include SSE3, SSE2, SSE and MMX optimizations.
SSE2 builds include SSE2, SSE and MMX optimizations.
SSE builds include SSE, MMX optimizations.

[jruggle]

@wisodev: and can you explain, please, the differences between all the aften.exe options?

I'll try to help a little here. I'm assuming you're talking about the different binaries at different revision points? If so:
The blog entry below gives a fairly detailed overview of changes between 0.06 and around rev 390 or so.
http://aftenblog.blogspot.com/2007/02/recent-changes.html

Since then, notable changes as documented in the Changelog are:
- added SSE version of window function
- added MMX and SSE2 versions of some exponent related functions
- removed old build system
- frame-independent variable bandwidth
- minimum and maximum bandwidth settings for variable bandwidth mode

If this is totally not what you were asking...then I'm sorry for taking up space. :)

edit: sorry...wiso got his reply in while I was writing mine. his reply probably more what you were looking for...

[Chumbo]

wisodev, thank you for the updated source. I wanted to help out the BeHappy people and do a quick recompile with the input/output vars exchanged positions, but I get errors in the build per this post (http://forum.doom9.org/showthread.php?p=965810#post965810). Any words of wisdom? Many thanks.

[wisodev]

wisodev, thank you for the updated source. I wanted to help out the BeHappy people and do a quick recompile with the input/output vars exchanged positions, but I get errors in the build per this post (http://forum.doom9.org/showthread.php?p=965810#post965810). Any words of wisdom? Many thanks.

BUILDING AFTEN

1. Get the latest sources from my website: http://win32builds.sourceforge.net/aften/index.html. Currently the latest are at revision 449 (http://prdownloads.sourceforge.net/win32builds/aften-svn-r449-src.rar?download).

2. To compile Aften using my build system you need the following software: Platform SDK (http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en) (latest version) or Visual Studio 2005 (http://msdn2.microsoft.com/en-us/vstudio/default.aspx) installed, Intel C++ Compiler 9.1 (http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cwin/279578.htm) and Yasm (http://www.tortall.net/projects/yasm/) compiler.

3. Get wav file (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Microsoft/6_Channel_ID.wav) used for PGO and save it somewhere on local disk.

4. Open batch script file windows\feedback.cmd in text editor and update it using instructions placed below.

Change this line:
set WAVFILES=I:\DOCS\WISO\AUDIO-BUILDS\AFTEN\TEST-WAV
where: I:\DOCS\WISO\AUDIO-BUILDS\AFTEN\TEST-WAV is path to directory containing wav file!

5. Open batch script file windows\build_intel.cmd in text editor and update it using instructions placed below.

Change this line:
@call "C:\Program Files\Intel\Compiler\C++\9.1\IA32\Bin\ICLVars.bat"
where: C:\Program Files\Intel\Compiler\C++\9.1\IA32\Bin\ICLVars.bat is full path to batch script witch is setting environment variables for Intel C++ Compiler.

Chnage this line:
set cmd_yasm="I:\DOCS\WISO\DEV\YASM\0.5.0\yasm-0.5.0-win32.exe"
where: I:\DOCS\WISO\DEV\YASM\0.5.0\yasm-0.5.0-win32.exe is full path to Yasm compiler.

6. Now run windows\build_win32.cmd batch script file to build all Win32 binaries. All the aften.exe files are placed in output sub-directories.

GUIDE NOTES

1. If you want to build only one binary, then execute command like this being in directory where builds script are placed:
@call build_intel.cmd 9_1 build_exe_pgo
You can find more available targets in windows\build_win32.cmd batch script file.

2. For Win64 builds the procedure is almost the same, but you naeed 64 bit OS and you use different batch script file windows\build_win64.cmd. I can provide guide if you need.

[Chumbo]

Thank you for the detailed response wiso. Much appreciated. :)

[mx101]

hi...

there is tutorials for aften?

what i need for aften works?

i download aften.06 and gui but not work somebody can help me with pakage im newbie sorry?

what i need for aften?


thanks and sorry:confused:

[Mug Funky]

to make aften work, you need:

- aften.exe
- a wav file
- a command line in the correct syntax.

saying "it wont wrok" isn't going to help us determine what's going wrong. is it giving you an error message? if so, what?

[LigH]

Ensure that you downloaded an executable / binary -- not the source code (assuming you don't want to compile it yourself)!

Apart from that: Details, details, details! What do you have? What did you do? How does it fail?

[jordisound]

Hi. I have a question about encoding ac3 with Aften.
Can aften encode 24 or 32bits 48000hz ac3 if the source is 24 or 32bits?

[LigH]

AC3 contains no integer samples, but floating point frequency parameters. Therefore, the resolution of the input does not really matter regarding the compression (only the available quality, the possible dynamic range).

And as far as I remember, Aften does not support any sample resolution except 16 bit at the moment...

[tebasuna51]

Hi. I have a question about encoding ac3 with Aften.
Can aften encode 24 or 32bits 48000hz ac3 if the source is 24 or 32bits?

Aften accept 32/44.1/48 KHz, 8/16/24/32 bit int and 32 bit float (at least) wav sources.

All formats are converted to 32 float internally before encode, but the quality is defined by the bitrate and not exist different samples sizes like in wav.

[LigH]

Thank you for the correction.

So my only point of criticism is expecting a 6-channel WAV for 6 channel input (which may easily scratch 4 GB limits) - but I know people are working on it.

[madshi]

Slightly OT, but still: if I decode an (E-)AC3 file and want to keep it as a wav file, would a 24bit integer wav file sound better than a 16bit integer wave file?

[jruggle]

Slightly OT, but still: if I decode an (E-)AC3 file and want to keep it as a wav file, would a 24bit integer wav file sound better than a 16bit integer wave file?

The short answer is yes. The AC-3 format can encode more dynamic range than 16-bit wav files. So using 24-bit would give better results.

[madshi]

@jruggle, thank you.

[vlada]

The short answer is yes. The AC-3 format can encode more dynamic range than 16-bit wav files. So using 24-bit would give better results.

And the longer answer would be, that probably no human will be able to hear the difference :-)

[HeadBangeR77]

Hello all, ;)
I don't want to launch a new thread on something, which is most probably obvious to you, yet it's unfortunately not so obvious to me...

I've been using the latest svn 467 with AftenGUI 1.3, and they work like charm and cooperate very well (thanks very much for constant developing and improving!). I assume the 467 revision isn't limited to 4GB wav files, yet I've encountered a problem on a previous stage: I can't find any application that would save my AC3 file (an original film soundtrack, 6 channels, 2h 23min 10sec long) to a proper 16 bit 5.1 wav file. I had first thought it was Aften's fault, since I didn't even check the size of the wav file (saved using the latest BeLight/BeSweet), however it turned out that the wav itself was only 4GB large and no more (about 2 hours long). Do you know any application, that bypasses this limit?

- DGIndex/DGDecode doesn't support saving to wav atm (there used to be some issues AFAIR)
- VirtualDubMod is only capable of creating a sort of dummy file, which is of the same file size as the AC3 track
- BeSweet/BeLight according to "BeSweet Commandline Reference Document version 2006-03-21 (BeSweet version 1.5b31)" is capable of saving 16 bit multichannel wav files up to 2GB (since I've got all the libraries updated, it made it up to 4GB)

***
A few questions about transcoding AC3 (I would like to keep 6 channels, yet improve the video a bit - I'm more sort of visual freak ;)) :
- The Guide (http://forum.doom9.org/showthread.php?t=56020) says the proper channel order is Front Left, Front Right, Front Center, Rear Left, Rear Right, and LFE
- my AC3 track, according to MediaInfo, is however a 448 kbps, 48 KHz, Front: L C R, Rear: L R, Subwoofer -> does it mean the order of front channels is wrong?
- BeSweet saves (according to the above mentioned document) to FL, FR, C, LFE, SL, SR -> again a different channel order?
- if I check the 3/2 coding mode + LFE in the GUI, it's as in the specifications, yet different from what my source is, and different from the wav file: should I just leave the fields empty and let the application read the information from the wav-header (if I finally happen to make one)?
- I would like to produce an AC3 file CBR 384 kbps with light compression: does anyone have any experience as to Film Light and Film Standard profiles?
- Should I check the low-pass filter, as in the AC3 specs, or leave it un-checked?

And thanks very much in advance!
cheers,
HDBR77

PS. Oops, that's quite a lot of uncertainties and questions from my side!

[Chumbo]

If you transcode from ac3 to ac3 using besweet, it uses azid, so you have to configure your output channels in the azid config screen as follows:

Channel 0 = Left
Channel 1 = Right
Channel 2 = Surround Left
Channel 3 = Surround Right
Channel 4 = Center
Channel 5 = LFE

[HeadBangeR77]

Hi!
I wanted to downmix to wav, so that I could make use of AftenGUI and the built-in compression profiles. I've also tried doing a direct transcoding with BeSweet/BeLight, and it throws at me the same errors as while trying to downmix to wav file (yet the downmixing has finished, transcoding is stuck at 87%, 0% CPU usage):


BeSweet v1.5b31 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using Shibatch.dll v0.25 by Naoki Shibata & DSPguru (shibatch.sourceforge.net).
Using bsn.dll replacement by Dimzon & Kurtnoise, Build Oct 2 2006, 16:07:39

Logging start : 03/22/07 , 01:54:59.

C:\Program Files\BeSweet\BeSweet.exe -core( -input I:\DVD\Black Pearl\AC3\Original AC3 Track.ac3 -output I:\DVD\Black Pearl\AC3\Original AC3 Track 1.ac3 -logfile I:\DVD\Black Pearl\AC3\Original AC3 Track.log ) -bsn( -exe aften.exe -b 384 -6chnew )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : I:\DVD\Black Pearl\AC3\Original AC3 Track.ac3
[00:00:00:000] | Output: I:\DVD\Black Pearl\AC3\Original AC3 Track 1.ac3
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 3/2, Bitrate: 448kbps
[00:00:00:000] | Total Gain: 0.000dB, Compression: None
[00:00:00:000] | LFE levels: To LR -INF, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +---------------------
[00:23:13.472] W7: Downmix overflow (2: +0.5dB)
[00:23:33.008] W7: Downmix overflow (2: +0.6dB)
[00:25:17.498] W7: Downmix overflow (2: +2.2dB)
[00:25:21.616] W7: Downmix overflow (2: +0.4dB)
[00:25:54.405] W7: Downmix overflow (2: +0dB)
[00:25:54.410] W7: Downmix overflow (2: +0dB)
[00:28:48.325] W7: Downmix overflow (2: +0dB)
[00:32:48.624] W7: Downmix overflow (2: +0.3dB)
[00:32:48.629] W7: Downmix overflow (2: +0dB)
[00:32:48.634] W7: Downmix overflow (2: +0.1dB)
[00:32:48.645] W7: Downmix overflow (2: +0.3dB)
[00:32:48.650] W7: Downmix overflow (2: +0.5dB)
[00:32:48.656] W7: Downmix overflow (2: +0.3dB)
[00:32:48.672] W7: Downmix overflow (2: +0.3dB)
[00:32:48.688] W7: Downmix overflow (2: +0.1dB)
[00:32:48.704] W7: Downmix overflow (2: +0.1dB)
[00:32:48.709] W7: Downmix overflow (2: +0dB)
[00:32:48.714] W7: Downmix overflow (2: +0dB)
[00:32:48.725] W7: Downmix overflow (2: +0.3dB)
[00:32:51.312] W7: Downmix overflow (2: +0.2dB)
[00:32:51.317] W7: Downmix overflow (2: +0.4dB)
[00:33:20.085] W7: Downmix overflow (2: +0.4dB)
[01:03:20.288] W7: Downmix overflow (0: +0.2dB)
[01:04:06.698] W7: Downmix overflow (0: +0.1dB)
[01:04:06.709] W7: Downmix overflow (0: +0.1dB)
[01:13:02.672] W7: Downmix overflow (2: +0.2dB)
[01:24:38.618] W7: Downmix overflow (2: +0dB)
[01:24:38.976] W7: Downmix overflow (2: +0dB)
[01:29:12.752] W7: Downmix overflow (0: +0.1dB)
[01:52:36.250] W7: Downmix overflow (2: +0.8dB)
[01:54:54.501] W7: Downmix overflow (2: +0.1dB)

The same "Downmix overflow" warning I used to get while downmixing to wav. :confused:

PS. BeSweet via BeLight didn't finish, because it hit the same boarder as while creating a 5.1 WAV - 2 hours and 4 minutes, which would make a 4GB wav file, as I assume.

PS2. BeLight GUI is still screwed (excuse me, Kurtnoise, it's late at night and I'm sick and tired of this): when I add anything into the advanced command line window, like e.g. "-readtoeof 1" for Aften, it disappears when I hit the run button.

PS.3 I'm trying right now to use the built-in Windows command line with "-readtoeof 1", curious what happens? ;)

@ Chumbo: I'm reading the docs, and correct me, if I'm wrong:
I should use azid's parameter -o l,r,sl,sr,c,lfe"? Why is that (I know you're much more experienced than I am in these matter, so that's why I'm asking)? How does it affect aften? Or will it take the order defined by azid?

[tebasuna51]

I can't find any application that would save my AC3 file (an original film soundtrack, 6 channels, 2h 23min 10sec long) to a proper 16 bit 5.1 wav file.
You can use:
- The command line decoder Azid 1.9 (http://www.doom9.org/Soft21/Audio/azid-1.9.zip)
- Foobar2000 with foo_ac3.dll
- The AviSynth decoder plugin NicAudio.dll with BeHappy/Bepipe/SoundOut
- The Guide (http://forum.doom9.org/showthread.php?t=56020) says the proper channel order is Front Left, Front Right, Front Center, Rear Left, Rear Right, and LFE
Don't say is the proper order only explain 3/2.1
This order is never used.
- my AC3 track, according to MediaInfo, is however a 448 kbps, 48 KHz, Front: L C R, Rear: L R, Subwoofer -> does it mean the order of front channels is wrong?
This is the internal correct order for an ac3 but not for a wav.
- BeSweet saves (according to the above mentioned document) to FL, FR, C, LFE, SL, SR -> again a different channel order?
This is the standard wav order. When you decode with azid you need put this parameters to obtain a correct 6 channel wav:
-d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr
With Foobar or NicAudio you obtain this order by default.
- if I check the 3/2 coding mode + LFE in the GUI, it's as in the specifications, yet different from what my source is, and different from the wav file: should I just leave the fields empty and let the application read the information from the wav-header (if I finally happen to make one)?
Just let the defaults, this fields have only sense for 3, 4 or 5 channels. For stereo and 5.1 only one mode is possible.
- I would like to produce an AC3 file CBR 384 kbps with light compression: does anyone have any experience as to Film Light and Film Standard profiles?
Warning, the Dynamic Range Compression is only for test pourpose because the actual results are far of Dolby recommended curves you can see at the mentioned Guide.
Use DRC at your risk.
- Should I check the low-pass filter, as in the AC3 specs, or leave it un-checked?
Sorry I never test this.

[tebasuna51]

If you transcode from ac3 to ac3 using besweet, it uses azid, so you have to configure your output channels in the azid config screen as follows:

Channel 0 = Left
Channel 1 = Right
Channel 2 = Surround Left
Channel 3 = Surround Right
Channel 4 = Center
Channel 5 = LFE
What is this azid config screen?
This map only can confuse and isn't correct.
Please forget the old BeSweetGUI, can't work with Aften.
With BeLight you don't need any remap.

[Chumbo]

Aha, yeah, I use the BeSweet gui and found I have to configure it this way when I transcode from ac3 to ac3. That's why, in the other thread, I was testing with BeHappy instead. But this channel mapping does work in BeSweet. I'll take a snapshot and put it up in a little while.

[EDIT] BeSweet azid settings:
http://img99.imageshack.us/img99/8683/besweetazidwk8.jpg

The only thing I use different is the dynamic compression. In the snapshot it's set to normal, but I use none normally which is in the pulldown list.

[tebasuna51]

I wanted to downmix to wav, so that I could make use of AftenGUI and the built-in compression profiles. I've also tried doing a direct transcoding with BeSweet/BeLight, and it throws at me the same errors as while trying to downmix to wav file
Don't worry with the "Downmix overflow" warning, are only some peaks cutted (only one > 1 db and not too much for 2 h.)

PS.3 I'm trying right now to use the built-in Windows command line with "-readtoeof 1", curious what happens?
Only work used in command line with aften.exe, not in command line with BeSweet

@ Chumbo: I'm reading the docs, and correct me, if I'm wrong:
I should use azid's parameter -o l,r,sl,sr,c,lfe"? Why is that (I know you're much more experienced than I am in these matter, so that's why I'm asking)? How does it affect aften? Or will it take the order defined by azid?
The -o azid parameter only work in command line with azid.exe, don't work with BeSweet. Y say you the correct parameters for azid are:

-d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr

The correct wav order is FL, FR, C, LFE, SL, SR.

[tebasuna51]

Aha, yeah, I use the BeSweet gui and found I have to configure it this way when I transcode from ac3 to ac3. That's why, in the other thread, I was testing with BeHappy instead. But this channel mapping does work in BeSweet. I'll take a snapshot and put it up in a little while.
BeSweetGUI is absolutely obsolete.
- The channel remapping is wrong.
- Use OTA for timestretch is obsolete.
- ac3enc is also obsolete
The only thing I use different is the dynamic compression. In the snapshot it's set to normal, but I use none normally which is in the pulldown list.
I agree, to transcode ac3 -> ac3 we never must apply the DRC at the decoder phase.

[Chumbo]

BeSweetGUI is absolutely obsolete.
- The channel remapping is wrong.
- Use OTA for timestretch is obsolete.
- ac3enc is also obsolete

That's fine, but if it ain't broke and it works... The channel mapping is not wrong. How can you say that? I've listened to the output tracks and they're absolutely correct. I've done this on many files. I wouldn't post bad or incorrect info if I hadn't used it successfully. Regardless of what's obsolete, it works. With that said, I'm trying to move to new tools as you know. ;)

[HeadBangeR77]

I'm very grateful for all the help, explanations, and suggestions! :)

1) I've finally understood the channel order (AC3's internal, and that of 5.1 WAVE).
2) Since I'm not familiar with foorbar2000, and the AviSynth-based applications have NET.framework dependency (or am I wrong? then plz correct me), I'm gonna try the standalone azid version. Yet my nose tells me I might hit the 4GB boarder again, since I did already twice while trying to transcode my AC3 file using BeLight/BeSweet or just the BeSweet's CMDL. Both azid's versions are the same (the standalone one and the one included with BeSweet package).
3) When I find some time to test, I'm gonna report back.

:thanks:
again and good night ;)

[Chumbo]

...@ Chumbo: I'm reading the docs, and correct me, if I'm wrong:
I should use azid's parameter -o l,r,sl,sr,c,lfe"? Why is that (I know you're much more experienced than I am in these matter, so that's why I'm asking)? How does it affect aften? Or will it take the order defined by azid?
I'm sorry, I misread your post. You're obviously using Aften and not azid. The settings are for azid. If you use aften, you don't have to worry about it. My bad, very sorry. And I'm not that experienced btw, but I try to help out with stuff I know has worked for me. :)

[tebasuna51]

2) Since I'm not familiar with foorbar2000, and the AviSynth-based applications have NET.framework dependency (or am I wrong? then plz correct me)
Yes for BeHappy/Bepipe, but you can use SoundOut (http://forum.doom9.org/showthread.php?t=120025) without .NET
I'm gonna try the standalone azid version. Yet my nose tells me I might hit the 4GB boarder again, since I did already twice while trying to transcode my AC3 file using BeLight/BeSweet or just the BeSweet's CMDL. Both azid's versions are the same (the standalone one and the one included with BeSweet package).

Yes is same version azid v1.9, but you can trust, the problem is BeSweet not azid.exe.

[HeadBangeR77]

Yes for BeHappy/Bepipe, but you can use SoundOut (http://forum.doom9.org/showthread.php?t=120025) without .NET
I really should have started a new thread, since this turns out to be a longer discussion. I saw the thread on SoundOut more than once, yet since I had never done any sound processing via AviSynth I was a bit sceptical (most probably because of lack of proper knowledge ;)).

I had some problems: first of all I have an AC3 source, so how do I load this kind of audio source in AviSynth? Or should I rip the VOBs again, so that they contain the audio track and call multiple "mpeg2source"s? Finally I went for DirectShowSource, and AC3 filter popped out then, decompressing the AC3 to 6 channel WAV, and sending it to the plugin (of course I had to reconfigure the AC3 Filter to not process anything on the way).

The results are rather poor:
1) The first 16-bit 5.1 WAV seems to be 4.60 GB, and so much it occupies on my HDD, Media Info indicates proper length and size, while Audio Identifier says it's only 622.63 MB and 18min 53sec long! And so see it both AftenGUI and SoundOut, when I load the file via WAVSource().
2) The same happened with my next trials (16-bit, and 24-bit WAVEs) - they occupy whole lot of space on my HDD, yet all audio processing applications see the above mentioned size and length, and so is the resulting Aften AC3 encode, when I try to process those files.
3) Could it be the fault of DirectShowSource() and AC3 Filter? Btw. the latter decodes the sound to WAV, with WAV channel order - hope SoundOut takes this into account?

The rest in a separate post.

If any moderator sees this, could he split this discussion form here (http://forum.doom9.org/showthread.php?p=973593#post973593)?
Thanks in advance!

PS. Got it thanks to NicAC3soource(), and SoundOut shows 6 channles (I have always though NicAudio was limited to 3?) - gonna encode now. :) Nic's forces 32-bit float, but I specified 24-bit integer in the SoundOut itself - hope this time I finally get the damned WAVE.

PS. NicAudio went on and created a huge 32-bit floating point WAV file. Wrrrr!

[tebasuna51]

That's fine, but if it ain't broke and it works... The channel mapping is not wrong. How can you say that? I've listened to the output tracks and they're absolutely correct. I've done this on many files. I wouldn't post bad or incorrect info if I hadn't used it successfully. Regardless of what's obsolete, it works. With that said, I'm trying to move to new tools as you know.

Sorry Chumbo for my rude answer, you are right this works but I'm also right this channel mapping are wrong, let me explain:

- the -ol,r,sl,sr,c,lfe parameter is ignored (like I say before and fortunately) in BeSweet-azid section. The order l,r,sl,sr,c,lfe is wrong, I don't know any soft than use this order.

- the channel mapping order in BeSweet is controlled by bsn.dll.

- Old bsn.dll generate wav's in ac3 order l,c,r,sl,sr,lfe (the same order necessary for ac3enc.dll, headac3he,... and supported by aften with the parameter -chmap 1)

- New bsn.dll (by Kurtnoise) generate wav's in standard wav order l,r,c,lfe,sl,sr and send this order to aften, but when send data to ac3enc is remapped to l,c,r,sl,sr,lfe like is needed.

This kind of mapping problems don't exist with BeLight, the new GUI for BeSweet, also support the last free encoders Aften, NeroAacEnc or CT enc_AacPlus, -soundtouch for timestretch and so on.

[HeadBangeR77]

Yes is same version azid v1.9, but you can trust, the problem is BeSweet not azid.exe.
I don't think I will use azid.exe, since I'm getting familiar with SoundOut and seem to make some progress, yet when I was trying it threw an error on me about "illegal output channel in line six":

(-f wav24 -d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr)

I really appreciate all your help, guys. :)
And Chumbo, thanks a lot for good intentions and your quick answers!

@ tebasuna51:
I'm constantly getting the same results with SondOut, no matter if I use DirectShowSource or NicAC3source - the file is huge, yet reported by most applications as much smaller, just 18 minute long, and so Aften sees it too. :confused:

[tebasuna51]

I don't think I will use azid.exe, since I'm getting familiar with SoundOut and seem to make some progress, yet when I was trying it threw an error on me about "illegal output channel in line six"
The correct sintax is:
azid.exe -F wav24 -d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr <ac3> <wav>
the parameters are case sensitive and 'f' have other meaning.
I'm constantly getting the same results with SondOut, no matter if I use DirectShowSource or NicAC3source - the file is huge, yet reported by most applications as much smaller, just 18 minute long, and so Aften sees it too.
You only can trust in wav size, the header fields than report the length to the app. are wrong.
Time_length = Size_in_bytes / (SampleRate x Num_channels x Bit_depth / 8)

For instance for a wav 48 KHz, 6 channels, 24 bit and 4.87 GB you have:

Time_length = 5229122682 / (48000 x 6 x 24 / 8) = 6052 sec = 1h. 40m. 52s.

To encode with aften (rev449 and next) you need the parameter: -readtoeof 1
This parameter are not yet implemented in AftenGUI or SoundOut GUI, you need execute something like:
NicAc3Source("G:\yourpath\input.ac3", DRC=0)
(process if any)
SoundOut(output="cmd", filename="G:\yourpath\output.ac3", autoclose=true, type=0, executable="G:\yourpath\aften.exe", prefilename="-v 0 -b 384 -readtoeof 1 -")

[HeadBangeR77]

The correct sintax is:
azid.exe -F wav24 -d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr <ac3> <wav>
the parameters are case sensitive and 'f' have other meaning.
I've finally found some time to drop by and report back. ;)

Thanks very much for the correction of my command line - it worked then, yet I think I'm gonna stick to the SoundOut plug-in, since then I can spare myself the step of creating a bloated WAV, and transcode AC3 => AC3 directly.
Great plug-in, btw., must dig in the thread some time.

You only can trust in wav size, the header fields than report the length to the app. are wrong.
Time_length = Size_in_bytes / (SampleRate x Num_channels x Bit_depth / 8)
For instance for a wav 48 KHz, 6 channels, 24 bit and 4.87 GB you have:
Time_length = 5229122682 / (48000 x 6 x 24 / 8) = 6052 sec = 1h. 40m. 52s.
Thanks for the tip. As already said before, creating e.g a 48 KHz, 6 channels, 24 bit WAV for a 2,5-hour film takes some storage place, that I don't have much currently. I've noted down the way to count the proper time length - cheers again. :)

Btw. all the applications that read just the header have reported the file size and duration of the "overflow" above 4 GB, interesting... I mean for instance: I had a 4.6GB WAV (as above, yet only 16 bit) with total duration of 2 hours and 23 minutes; it was reported as 6XX MB file with a total playing time of about 18 minutes, instead of e.g. 4GB file, 2 hours 4-5 minutes. Do you happen know why is it so?

To encode with aften (rev449 and next) you need the parameter: -readtoeof 1
This parameter are not yet implemented in AftenGUI or SoundOut GUI, you need execute something like:
Yes, I've marked there is no way to add a custom parameter like the above one with Aften GUI 1.3, SoundOut GUI however has got some custom command line options interface. Is it not working properly yet?


NicAc3Source("G:\yourpath\input.ac3", DRC=0)
(process if any)
SoundOut(output="cmd", filename="G:\yourpath\output.ac3", autoclose=true, type=0, executable="G:\yourpath\aften.exe", prefilename="-v 0 -b 384 -readtoeof 1 -")

NicAc3Source doesn't know the DRC parameter, at least the version I have. It worked for me like charm with:

NicAC3Source("I:\DVD\Black Pearl\AC3\Original AC3 Track.ac3")

SoundOut(output="cmd", filename="I:\DVD\Black Pearl\AC3\New AC3 Track.ac3", autoclose=true, type=0, executable="I:\DVD\Black Pearl\AftenGUI-1.3\aften.exe", prefilename="-v 0 -b 384 -dnorm 31 -dynrng 5 -readtoeof 1 -")
I know dnorm is 31 by default, and dynrng is 5 by default (which means no compression), yet I'm used to writing those parameters, that I might change in the future, in the command line nonetheless.

As to some tweaking:
- -bwfilter 1 I can't notice any difference in audio,
- dynrng 0 (which is "Film Light") is indeed very, very subtle. It might be not up to the specs, yet I think I'm gonna stick to it, since I really like the end effect

[i]"The full dynamic range audio is still encoded, but a code is given for each block which tells the decoder to adjust the output volume for that block."[i](Aften HELP file)
Does that mean the changes could be reverted?

And really the last of my questions:
I remember reading somewhere Aften adds some extra frames while transcoding /encoding. In my case the difference is:
02:23:10.944 original AC3 vs. 02:23:10.976 Aften

Does it take place somewhere at the beginning of the file? If so, I could just add a "-32ms" delay while muxing with video, and the slight asynchronisation should be gone, shouldn't it?

Thank you very much for all the help - really appreciated! :)
cheers,
HDBR77

[jruggle]

As to some tweaking:
- -bwfilter 1 I can't notice any difference in audio,

It will never be extremely noticeable...especially when the cutoff is near the upper limit of human hearing. I included the option because it's one of Dolby's recommended pre-encoding filters.


[i]"The full dynamic range audio is still encoded, but a code is given for each block which tells the decoder to adjust the output volume for that block."[i](Aften HELP file)
Does that mean the changes could be reverted?

Yes, if you have the right tool to do that. I don't know of any, though there is probably some professional software somewhere which can do that.


And really the last of my questions:
I remember reading somewhere Aften adds some extra frames while transcoding /encoding. In my case the difference is:
02:23:10.944 original AC3 vs. 02:23:10.976 Aften

Does it take place somewhere at the beginning of the file? If so, I could just add a "-32ms" delay while muxing with video, and the slight asynchronisation should be gone, shouldn't it?

the option to use is '-pad 0'

[tebasuna51]

Btw. all the applications that read just the header have reported the file size and duration of the "overflow" above 4 GB, interesting... I mean for instance: I had a 4.6GB WAV (as above, yet only 16 bit) with total duration of 2 hours and 23 minutes; it was reported as 6XX MB file with a total playing time of about 18 minutes, instead of e.g. 4GB file, 2 hours 4-5 minutes. Do you happen know why is it so?
There are two fields (filesize and datasize with 4 bytes each) in wav header than can't support a number greater than 2^32 (like 4 GB), when these counters overflow begin by 0 another time.

Yes, I've marked there is no way to add a custom parameter like the above one with Aften GUI 1.3, SoundOut GUI however has got some custom command line options interface. Is it not working properly yet?
Before Aften 0.06 the default was similar to -readtoeof 1 then GUI's don't need to put this. AFAIK only BeHappy have the GUI actualized :rolleyes:

NicAc3Source doesn't know the DRC parameter, at least the version I have.
Please use the last NicAudio.dll (http://nic.dnsalias.com/NicAudio_alpha3.zip), not only for DRC options but also to avoid crash with 44.1 KHz signals and others issues.
[i]"The full dynamic range audio is still encoded, but a code is given for each block which tells the decoder to adjust the output volume for that block."[i](Aften HELP file)
Does that mean the changes could be reverted?
With DRC=0 in NicAc3Source or with DRC='None' in BeLight-BeSweet-Azid this code per block is ignored and the full dynamic range is decoded.
Does it take place somewhere at the beginning of the file? If so, I could just add a "-32ms" delay while muxing with video, and the slight asynchronisation should be gone, shouldn't it?
Really the delay is only 5.33 ms (in 48 KHz.) the rest to 32 ms is silence at the end, but you can use -pad 0 like Justin say to have a exact sync (now the first 5.33 ms are encoded properly only if are silence)

[HeadBangeR77]

@ jruggle:
Thank you very much for clarifying. :)

@ tebasuna51:
I've got to thank you one more time for all the explanations. :)
I used to have some older (most probably the last official/stable) version of NicAudio plug-in, dated July 2005, and it didn't accept the DRC parameter - thanks for linking to a newer version. Everything seems now very clear to me, and I hope my endless questions and your explanations can be of any use for other people. ;)

cheers,
HDBR77

[chros]

Please use the last NicAudio.dll (http://nic.dnsalias.com/NicAudio_alpha3.zip), not only for DRC options but also to avoid crash with 44.1 KHz signals and others issues.
Isn't this the same as in Nic's page (http://nic.dnsalias.com/nixaudiostuff.html) v1.7 ? (the filesize is the same)

[madshi]

Some theoretical questions to the (E-)AC3 gurus:

(1) Which bitdepth are studios encoding (E-)AC3 in? 16bit? 20bit? 24bit? 32bit integer? 32bit float?
(2) Does the bitdepth make a difference for the final (E-)AC3 file size? Does the (E-)AC3 file size get bigger with more input bitdepth?
(3) Is there a way to find out which bitdepth a given (E-)AC3 track was encoded with?
(4) If a (E-)AC3 file was encoded with 16bit, does decoding to more than 16bit still have any advantage whatsoever?

[tebasuna51]

Isn't this the same as in Nic's page (http://nic.dnsalias.com/nixaudiostuff.html) v1.7 ? (the filesize is the same)
Yes, is the same bit to bit and date 2006-09-01, seems Nic was add in their web at 2007-02-24 like NicAudio.dll v1.7. Thanks.

[jruggle]

Some theoretical questions to the (E-)AC3 gurus:

(1) Which bitdepth are studios encoding (E-)AC3 in? 16bit? 20bit? 24bit? 32bit integer? 32bit float?

Technically, there is no way to know from the generated content alone. The AC3 format does not have a specified bit depth. The best way I can come up with to describe it simply is that each sample varies from 5-bit to 21-bit floating point. But even this is somewhat misleading because AC3 stores audio in the frequency domain, not in the time domain like in PCM audio.


(2) Does the bitdepth make a difference for the final (E-)AC3 file size? Does the (E-)AC3 file size get bigger with more input bitdepth?

No. The user doing the encoding controls the file size by specifying the bit rate.


(3) Is there a way to find out which bitdepth a given (E-)AC3 track was encoded with?

No, not unless the person who encoded it tells you. :)


(4) If a (E-)AC3 file was encoded with 16bit, does decoding to more than 16bit still have any advantage whatsoever?
If you do happen to know that the source was 16-bit, then decoding to more than 16-bit can still (theoretically) give better results. Better is relative here though. I doubt that the difference would even be audible to most people.

[Mug Funky]

authoring houses will most likely be using DA-88 masters. these are usually in 16/48, though they can carry up to 24/96 in theory.

i've never seen one of these in anything other than 16/48, but i've never encoded for HD-DVD before either.

[madshi]

Thanks jruggle (and Mug Funky) for the very informative reply!

[jruggle]

Aften 0.07 was released today, 25 April 2007. Here is the Changelog:

added C++ bindings (pass -DBINDINGS_CXX=1 to cmake to build them)
API change of helper functions
new and more precise bitalloc algorithm
parallelization
optional faster exponent strategy decision
added SSE version of window function
added MMX and SSE2 versions of some exponent related functions
removed old build system
frame-independent variable bandwidth
minimum and maximum bandwidth settings for variable bandwidth mode
altivec support framework (by David Conrad)
altivec MDCT (by David Conrad)

[madshi]

Thank you!!

From what I can see, most of these changes are targetted at better performance, correct? Does "new and more precise bitalloc algorithm" also indicate improved quality?

[Kurtnoise]

@Justin or Prakash : by default, cmake enables SSSE3 during compilation, right ? coz aften crashes on machines which haven't these CPU optimizations (just tried on a Linux distro...I've got a segfault (core dumped) when I try to use aften. So, how turn off SSSE3 detection with cmake (except disable some parts in the code) ?

[jruggle]

Thank you!!

From what I can see, most of these changes are targetted at better performance, correct? Does "new and more precise bitalloc algorithm" also indicate improved quality?

There is no quality difference there. The bit allocation search results used to differ very slightly for each run when using multiple threads. The algorithm was fixed to give the same exact results for each run.

[jruggle]

@Justin or Prakash : by default, cmake enables SSSE3 during compilation, right ? coz aften crashes on machines which haven't these CPU optimizations (just tried on a Linux distro...I've got a segfault (core dumped) when I try to use aften. So, how turn off SSSE3 detection with cmake (except disable some parts in the code) ?

Could you give more detailed info on this? I use Linux and my machine doesn't have any form of SSE whatsoever, but I haven't had any issues. Even though my system compiles the SSE parts, the runtime CPU detection prevents them from being used.

The kind of issue you're talking about should give an "Illegal Instruction" not a segfault. Can you enable debugging and provide a gdb backtrace?

[DarkAvenger]

Aften has no SSSE3 code (only detection), but has SSE3, but it should not be used on CPUs w/o SSE3. Are you supplying custom (non-portable) CFLAGS?

[Kurtnoise]

Nope...I used the default CFLAGS. My own PC (i.e the one on which I compile Aften) supports SSE3 as well but not SSSE3.

I tried to debug with gdb backtrace but I've got "No Stack" as response. It's really new for me the debugging on Linux. Sorry. I'll investigate in more details later...

[Chumbo]

Just fyi, the links in the first post don't have 0.07 listed when you navigate to either one:
http://sourceforge.net/projects/aften

or

http://kurtnoise.free.fr/index.php?dir=Aften/

[Chainmax]

This is progressing very nicely, thanks for the new release Justin :).

[Fizick]

When I try open in IE or Opera the link:
http://kurtnoise.free.fr/index.php?dir=Aften/

I have got an error message only:

Incorrect format for file ./languages/ru.txt on line 1.
Format is "variable name[tab]value"

[tebasuna51]

Waiting for a windows binary aften 0.07 (the last 0.06 have problems with big files) I recommend use aften rev490 24 April 2007, from wisodev.

Changes 491, 492 and 493, 25 April 2007, are only in text files (readme, changelog, cmakelist) without changes in functionality.

Edit: link removed because aften 0.07 by Wisodev (thanks to you) available.

[Kurtnoise]

When I try open in IE or Opera the link:
http://kurtnoise.free.fr/index.php?dir=Aften/

I have got an error message only:

Incorrect format for file ./languages/ru.txt on line 1.
Format is "variable name[tab]value"


Use the old entry instead : http://kurtnoise.free.fr/Aften ...There is a bug in the PHP code for the russian language detection.


About a new compile : still doesn't work properly here...Maybe Wisodev should try himself coz he doesn't use CMake files for compilation.

[wisodev]

Here are my Aften version 0.07 optimized builds for Win32 and Win64.

Download binaries for Win32:
aften-0.07-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.zip?download) (2 658 303 bytes)
aften-0.07-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.rar?download) (501 676 bytes)
aften-0.07-win32-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.7z?download) (493 666 bytes)
Download binaries for Win64:
aften-0.07-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.zip?download) (881 151 bytes)
aften-0.07-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.rar?download) (320 881 bytes)
aften-0.07-win64-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.7z?download) (306 845 bytes)
Download my patched sources with build scripts:
aften-0.07-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.zip?download) (159 557 bytes)
aften-0.07-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.rar?download) (82 861 bytes)
aften-0.07-src.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.7z?download) (81 052 bytes)

Official website (http://win32builds.sourceforge.net/aften/index.html) for my builds.

Thanks,
wisodev

[Chumbo]

Here are my Aften version 0.07 optimized builds for Win32 and Win64.

Download binaries for Win32:
aften-0.07-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.zip?download) (2 658 303 bytes)
aften-0.07-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.rar?download) (501 676 bytes)
aften-0.07-win32-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.7z?download) (493 666 bytes)
Download binaries for Win64:
aften-0.07-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.zip?download) (881 151 bytes)
aften-0.07-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.rar?download) (320 881 bytes)
aften-0.07-win64-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.7z?download) (306 845 bytes)
Download my patched sources with build scripts:
aften-0.07-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.zip?download) (159 557 bytes)
aften-0.07-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.rar?download) (82 861 bytes)
aften-0.07-src.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.7z?download) (81 052 bytes)

Official website (http://win32builds.sourceforge.net/aften/index.html) for my builds.

Thanks,
wisodev

VERY much appreciated wisodev! :)

[Mr_Odwin]

Does "optimised for win32 and win64" mean that they won;t work on the other operating system. I.e. will the win32 version work all right on a win64 system?
And, is there a version that will work on a generic processor? (If you were including aften as part of a download package which version from the packs above should be chosen to be compatible with all processors?)

[Boulder]

I believe that there's an MMX build in the package which would work on most processors.

[wisodev]

Does "optimised for win32 and win64" mean that they won;t work on the other operating system. I.e. will the win32 version work all right on a win64 system?
And, is there a version that will work on a generic processor? (If you were including aften as part of a download package which version from the packs above should be chosen to be compatible with all processors?)

The Win32 builds work under Win64 operating systems (for example they work without any problems under Windows XP x64, Windows Server 2003 x64 and Vista x64). The Win64 binaries are native binaries so they only work under Win64 OS.

The most generic binary is placed in exe_pgo directory (win32 binaries archive) and it is the most compatible build to include in any software pack.

[DarkAvenger]

@kurtnoise

I tried the svn version on AthlonXP with linux x86 - and no probs. Do you have the same problem with svn version, as well? It would really be helpfull if you could find out where exactly the crash occurs. Maybe you could compile with CFLAGS="-O0 -g3" (delete cmake cache before) and try gdb again.

[Kurtnoise]

Hi,

Sorry for the delay...So here it is :
(gdb) run -b 448 ~/Des_accords.wav ~/Test1.ac3
Starting program: /home/lionel/aften/default/aften -b 448 ~/Des_accords.wav ~/Test1.ac3
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1210759488 (LWP 9234)]

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210759488 (LWP 9234)]
0x0806c2ea in sse2_process_exponents ()
(gdb)

I used gcc 4.1 / nasm 0.98.38 . I'm running on Debian Sid 4.0 with an AMD 64 3200+. Same crash with 0.07 bundle or svn build. Is that enough ?

[SealTooGreat]

Does Aften support WAV 7 channel input. If does, what is the channel order mapping. I want to encode to AC3 6.1 EX with "LFE channel is present"
Which program can I use to connect 7 separated mono WAV? Cause Sound Forge doesn't allow me that kind of exporting.
BTW those 7 channels are created from stereo using Sony Sound Forge 9 + SRS Circle Surround VST Pro Decoder.
One more thing, can Aften handle separated mono wav input?
Sorry if I've asked same repeated questions, didn't have time to read whole thread and in downloaded EncWAVtoAC3-0.4-bin I couldn't find that info.

[jruggle]

Does Aften support WAV 7 channel input. If does, what is the channel order mapping. I want to encode to AC3 6.1 EX with "LFE channel is present"
Which program can I use to connect 7 separated mono WAV? Cause Sound Forge doesn't allow me that kind of exporting.
BTW those 7 channels are created from stereo using Sony Sound Forge 9 + SRS Circle Surround VST Pro Decoder.
One more thing, can Aften handle separated mono wav input?
Sorry if I've asked same repeated questions, didn't have time to read whole thread and in downloaded EncWAVtoAC3-0.4-bin I couldn't find that info.
From what little I know about it, I think that EX is still 5.1, but emulates 6.1 by matrixing a rear surround into the left and right surround. AC-3 does not support more than 5.1 channels. E-AC-3 supports it, but Aften does not encode E-AC-3 yet.

[SealTooGreat]

... but Aften does not encode E-AC-3 yet.
Are You sure that E-AC-3 will supported in the future?

[jruggle]

Are You sure that E-AC-3 will supported in the future?
Yes. I thought about implementing it soon, but I really don't have a way to test the output. But by the end of the summer there will be an open-source E-AC-3 decoder, so that will allow me to do proper testing.

[chros]

Yes. I thought about implementing it soon, but I really don't have a way to test the output. But by the end of the summer there will be an open-source E-AC-3 decoder, so that will allow me to do proper testing.
You can use gabest's ac3filter modified by orbitlee and Sonic Decoder Pack 4.2 to try out eac3 files.

[Kurtnoise]

Justin doesn't run on Windows and Sonic bundle is a shareware...;)

[chros]

Justin doesn't run on Windows...
Ahaa, I get it ! :)

[jruggle]

Justin doesn't run on Windows and Sonic bundle is a shareware...;)

Ahaa, I get it ! :)

Yeah, I should've mentioned that. I don't charge for software, and I don't pay for software. I figure that if I really have a need for something that isn't already implemented in open source, I should do it myself. In this case, I'm at least helping out by mentoring a student who is producing an E-AC-3 decoder for FFmpeg as part of Google's Summer of Code program.

[Kurtnoise]

@Justin or Prakash : any news about my segfault ?

More gdb infos :
lionel@debian:~/aften/default$ gdb ./aften
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run -b 448 ~/Club.wav ~/Test2.ac3
Starting program: /home/lionel/aften/default/aften -b 448 ~/Club.wav ~/Test2.ac3
[Thread debugging using libthread_db enabled]
[New Thread -1210399040 (LWP 7929)]

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210399040 (LWP 7929)]
0x0806cd13 in sse2_process_exponents ()
(gdb) bt
#0 0x0806cd13 in sse2_process_exponents ()
#1 0xb7eeb120 in ?? () from /lib/tls/i686/cmov/libc.so.6
#2 0x00000219 in ?? ()
#3 0xb7eeb144 in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7eeb144 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0x00000000 in ?? ()
(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0x806ccf3 to 0x806cd33:
0x0806ccf3 <sse2_process_exponents+6147>: pushf
0x0806ccf4 <sse2_process_exponents+6148>: and $0xc8,%al
0x0806ccf6 <sse2_process_exponents+6150>: add %al,(%eax)
0x0806ccf8 <sse2_process_exponents+6152>: add %cl,0xdc24ac(%ebx)
0x0806ccfe <sse2_process_exponents+6158>: add %al,(%eax)
0x0806cd00 <sse2_process_exponents+6160>: test %esi,%esi
0x0806cd02 <sse2_process_exponents+6162>: mov 0xfffffffc(%ebp,%ebx,4),%ecx
0x0806cd06 <sse2_process_exponents+6166>: jle 0x806d17b <sse2_process_exponents+7307>
0x0806cd0c <sse2_process_exponents+6172>: mov 0xb4(%esp),%ebx
0x0806cd13 <sse2_process_exponents+6179>: movdqu (%ecx),%xmm0
0x0806cd17 <sse2_process_exponents+6183>: movdqa %xmm5,%xmm2
0x0806cd1b <sse2_process_exponents+6187>: mov $0x10,%edx
0x0806cd20 <sse2_process_exponents+6192>: lea 0xffffffff(%ebx),%eax
0x0806cd23 <sse2_process_exponents+6195>: mov 0xcc(%esp),%ebx
0x0806cd2a <sse2_process_exponents+6202>: shr $0x4,%eax
0x0806cd2d <sse2_process_exponents+6205>: and $0x1,%eax
0x0806cd30 <sse2_process_exponents+6208>: cmpl $0x10,0xb4(%esp)
End of assembler dump.
(gdb) info all-registers
eax 0x6 6
ecx 0x30303060 808464480
edx 0x3 3
ebx 0xf0 240
esp 0xbfa5de10 0xbfa5de10
ebp 0xbfa5e528 0xbfa5e528
esi 0xf0 240
edi 0x5 5
eip 0x806cd13 0x806cd13 <sse2_process_exponents+6179>
eflags 0x210206 [ PF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
st0 3.5821711910336390903074238806631572e-15 (raw 0x3fcf810fb2958f648000)
st1 -2.4515507845990214264020323753356934e-08 (raw 0xbfe5d2962c0000000000)
st2 6.5240285009447156406362713407295607e-11 (raw 0x3fdd8f7703f1baf3d152)
st3 -5.9851242184549846570007503032684326e-08 (raw 0xbfe780879---Type <return> to continue, or q <return> to quit---
18000000000)
st4 -4.7593488261554739437997341156005859e-08 (raw 0xbfe6cc69980000000000)
st5 3.5335734338559632305987179279327393e-08 (raw 0x3fe697c40d0000000000)
st6 0 (raw 0x00000000000000000000)
st7 16777216 (raw 0x40178000000000000000)
fctrl 0x37f 895
fstat 0x20 32
ftag 0xffff 65535
fiseg 0x0 0
fioff 0x0 0
foseg 0x0 0
fooff 0x0 0
fop 0x0 0
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x13,
0x13, 0x0, 0x0, 0x13, 0x13}, v8_int16 = {0x0, 0x1212, 0x0, 0x1212, 0x0,
0x1313, 0x0, 0x1313}, v4_int32 = {0x12120000, 0x12120000, 0x13130000,
0x13130000}, v2_int64 = {0x1212000012120000, 0x1313000013130000},
uint128 = 0x13130000131300001212000012120000}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x0, 0x14, 0x14, 0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x12,
---Type <return> to continue, or q <return> to quit---
0x12, 0x0, 0x0, 0x14, 0x14}, v8_int16 = {0x0, 0x1414, 0x0, 0x1212, 0x0,
0x1212, 0x0, 0x1414}, v4_int32 = {0x14140000, 0x12120000, 0x12120000,
0x14140000}, v2_int64 = {0x1212000014140000, 0x1414000012120000},
uint128 = 0x14140000121200001212000014140000}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x12, 0x0, 0x0, 0x0, 0x12, 0x0, 0x0, 0x0, 0x13, 0x0, 0x0,
0x0, 0x13, 0x0, 0x0}, v8_int16 = {0x1200, 0x0, 0x1200, 0x0, 0x1300, 0x0,
0x1300, 0x0}, v4_int32 = {0x1200, 0x1200, 0x1300, 0x1300}, v2_int64 = {
0x120000001200, 0x130000001300},
uint128 = 0x00001300000013000000120000001200}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x14, 0x14, 0x14, 0x14, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12,
0x12, 0x12, 0x14, 0x14, 0x14, 0x14}, v8_int16 = {0x1414, 0x1414, 0x1212,
0x1212, 0x1212, 0x1212, 0x1414, 0x1414}, v4_int32 = {0x14141414,
0x12121212, 0x12121212, 0x14141414}, v2_int64 = {0x1212121214141414,
0x1414141412121212}, uint128 = 0x14141414121212121212121214141414}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x16, 0x16,
0x16, 0x16, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x1414, 0x1414, 0x1414,
0x1414, 0x1616, 0x1616, 0x0, 0x0}, v4_int32 = {0x14141414, 0x14141414,
0x16161616, 0x0}, v2_int64 = {0x1414141414141414, 0x16161616},
uint128 = 0x00000000161616161414141414141414}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
---Type <return> to continue, or q <return> to quit---
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x00000000000000000000000000000000}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x14, 0x0, 0x0, 0x0, 0x14, 0x0, 0x0, 0x0, 0x16, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x1400, 0x0, 0x1400, 0x0, 0x1600, 0x0,
0x0, 0x0}, v4_int32 = {0x1400, 0x1400, 0x1600, 0x0}, v2_int64 = {
0x140000001400, 0x1600}, uint128 = 0x00000000000016000000140000001400}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x13, 0x13,
0x13, 0x13, 0x13, 0x13, 0x13, 0x13}, v8_int16 = {0x1212, 0x1212, 0x1212,
0x1212, 0x1313, 0x1313, 0x1313, 0x1313}, v4_int32 = {0x12121212,
0x12121212, 0x13131313, 0x13131313}, v2_int64 = {0x1212121212121212,
0x1313131313131313}, uint128 = 0x13131313131313131212121212121212}
mxcsr 0x1fa0 [ PE IM DM ZM OM UM PM ]
mm0 {uint64 = 0x810fb2958f648000, v2_int32 = {0x8f648000,
0x810fb295}, v4_int16 = {0x8000, 0x8f64, 0xb295, 0x810f}, v8_int8 = {0x0,
0x80, 0x64, 0x8f, 0x95, 0xb2, 0xf, 0x81}}
mm1 {uint64 = 0xd2962c0000000000, v2_int32 = {0x0, 0xd2962c00},
v4_int16 = {0x0, 0x0, 0x2c00, 0xd296}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x2c, 0x96, 0xd2}}
mm2 {uint64 = 0x8f7703f1baf3d152, v2_int32 = {0xbaf3d152,
0x8f7703f1}, v4_int16 = {0xd152, 0xbaf3, 0x3f1, 0x8f77}, v8_int8 = {0x52,
---Type <return> to continue, or q <return> to quit---
0xd1, 0xf3, 0xba, 0xf1, 0x3, 0x77, 0x8f}}
mm3 {uint64 = 0x8087918000000000, v2_int32 = {0x0, 0x80879180},
v4_int16 = {0x0, 0x0, 0x9180, 0x8087}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x80,
0x91, 0x87, 0x80}}
mm4 {uint64 = 0xcc69980000000000, v2_int32 = {0x0, 0xcc699800},
v4_int16 = {0x0, 0x0, 0x9800, 0xcc69}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x98, 0x69, 0xcc}}
mm5 {uint64 = 0x97c40d0000000000, v2_int32 = {0x0, 0x97c40d00},
v4_int16 = {0x0, 0x0, 0xd00, 0x97c4}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0xd, 0xc4, 0x97}}
mm6 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm7 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000},
v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x80}}
(gdb)
Hope this helps...I've also reported the bug on SF just for reminding.

[DarkAvenger]

Well, it's crashing at this instruction


0x0806cd13 <sse2_process_exponents+6179>: movdqu (%ecx),%xmm0


It is an unaligned load, so it can't crash because of alignment issues. Could you try running aften with valgrind? I really don't understand why it crashes there. Could you try a different compiler?

[Kurtnoise]

Could you try running aften with valgrind?
lionel@debian:~/aften/default$ valgrind --tool=memcheck ./aften -b 448 ~/Club.wav ~/Test2.ac3
==5771== Memcheck, a memory error detector.
==5771== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5771== Using LibVEX rev 1658, a library for dynamic binary translation.
==5771== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5771== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==5771== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5771== For more details, rerun with: -v
==5771==

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)

==5771== Use of uninitialised value of size 4
==5771== at 0x806CD13: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CDAB: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CDB0: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CE90: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022E75: memcpy (mc_replace_strmem.c:77)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022E8A: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022EDF: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x4022EF1: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D089: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0BA: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0D7: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0E2: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0ED: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0F8: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D103: sse2_process_exponents (in /home/lionel/aften/default/aften)
progress: 100% | q: 322.0 | bw: 60.0 | bitrate: 448.0 kbps

==5771==
==5771== ERROR SUMMARY: 494513 errors from 15 contexts (suppressed: 15 from 1)
==5771== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5771== malloc/free: 6,902 allocs, 6,902 frees, 42,562,104 bytes allocated.
==5771== For counts of detected errors, rerun with: -v
==5771== All heap blocks were freed -- no leaks are possible.

I really don't understand why it crashes there. Could you try a different compiler?
Tried with gcc 4.0/4.1.x, same crash. I'll try with the msvc compiler later...

Tebasuna told me also that this crash has been occured after rev 490 iirc...I can make a regression test if you want.

[tebasuna51]

Tebasuna told me also that this crash has been occured after rev 490 iirc...I can make a regression test if you want.
Yes, the problem is between rev475 (work) and rev484 (crash)

[DarkAvenger]

@kurtnoise13

Please make a debug build (delete cmake cache and run with CFLAGS="-O0 -g3" cmake) and try running with valgrind again. That would be a lot more informative.


Does the MMX routine of that function crash for you? (Run with valgrind, as well, please.) Just hack the cpu_caps_have_sse2 routine to always return 0.

It is interesting that valgrind doesn't mention any problems for me...

@tebasuna51

Does rev 477 crash, as well?


Aaargh, I think I found the bug. Please try current svn.

@Justin

I think next time send release candidates to kurtnoise13, as well. It seems my test sample doesn't catch all bugs. :( I also think we need a quick new release as well. Sorry.

[Kurtnoise]

Aaargh, I think I found the bug. Please try current svn.
rev 510 works fine now. Many thanks...:)

[Kurtnoise]

erff...I spoke too fast. It works fine on Linux but not on Windows. :(


edit: it works when I disable sse2/sse3 routines and with the msvc compiler.

[DarkAvenger]

Does it crash at the same position? Could you try to make a debug build and try to find out where it crashes in the source?

[Kurtnoise]

Yeah, I suspect the crash at the same position but to be sure which free tool(s) is(are) available on win32 plateform to debug/find out those kind of crashes ?

[DarkAvenger]

Well, for msvc there whould be winedbg or the vc express ide - but I never tried it with c.

For mingw you can use gdb - which I did:

Anyway I found it crashing with mingw, as well - at a slightlxy different position. This time is was an alignment issue. Please check whether rev 511 fixes this issue.

[Kurtnoise]

Allright, rev 511 fixes this bug. Many thanks to you...again. :)

[DarkAvenger]

Thanks for your time in testing/debugging, as well. :)

[wisodev]

I was just testing my new Aften builds from svn sources at revision 511 (file: aften-svn-r511-vs2005.zip) (http://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924) using Visual Studio 2005 and comparing speed with Kurtnoise13 build (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev511.zip) and Kurtnoise13 Aften build again crushed (my build runs ok) on my system (WinXP SP2 x86, Athlon64 X2 3600+) in the same place as the last bug.

Here is debuger output (VS2005), the yellow arrow shows place where Aften crushed:
http://img61.imageshack.us/img61/4746/crushaftenr511knfc8.th.jpg (http://img61.imageshack.us/my.php?image=crushaftenr511knfc8.jpg)

[tebasuna51]

Here work fine both rev511 (Kurtnoise, wisodev).
XP SP1, P4 2400

[wisodev]

I found the crush reason!

Kurtnoise13 r511 build does not work on multi core CPUs!

I have 2 core CPU, when I run under VMware machine (WinXP SP2) with enabled one core only then Kurtnoise13 build works.

Maybe there is some issue with multi-threading?

PS. All VS2005 have multi-threading enabled, but the Intel Compiler builds are working with and without MT on my machine.

[DarkAvenger]

@wisodev

Could you try compiling aften using cmake and msvc (nmake makefiles) and report back?

I don't have windows on a multi core machine, so I cannot really test.

BTW, I'll be flying off tomorrow for 3.5 weeks and thus won't be able to work on aften for this timespan.

The suggested work-around is then to pass -threads 1 parameter.

Update:

I think I found the place where it crashes, but it is at a different possition:

x86_sse2_exponent.c, line 335. The problem is probably line 325, where I do an aligned load, which is ok, as at line 287 I told the freaking compiler to align the static 2dim array. It seems that crappy mingw gcc compiler kurtnoise13 is using messes this up and doesn't align that array. Grrr.
Quick and dirty solution: Change the aligned load to and unaligned, ie, change _mm_load_si128 to _mm_loadu_si128.
Correct solution: fix the compiler...

I had this problem once at another place. I think gcc is somewhat brokne regarding alignment of multi dim static arrays. Seems I need to work-around this. (No I don't want to change that aligned load, as is sacrifices speed).
Perhaps it is enough to move the array to before the three ints?

[wisodev]

@wisodev

Could you try compiling aften using cmake and msvc (nmake makefiles) and report back?

I don't have windows on a multi core machine, so I cannot really test.

BTW, I'll be flying off tomorrow for 3.5 weeks and thus won't be able to work on aften for this timespan.

The suggested work-around is then to pass -threads 1 parameter.


OK. I will do some tests with cmake builds and msvc.

[DarkNite]

I may have missed something, and apologize if this has already been addressed elsewhere. I see rev512 (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev512.zip) has been posted, but there's no comments in this thread or a changelog in the the archive.

Has the multicore issue been addressed? I won't be able to test on a multicore win32 machine for a few days. I would gladly test this (or any other) build during the weekend if no one else has free time.

[Kurtnoise]

I may have missed something, and apologize if this has already been addressed elsewhere. I see rev512 (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev512.zip) has been posted, but there's no comments in this thread or a changelog in the the archive.
#585 from this thread...
I think I found the place where it crashes, but it is at a different possition:

x86_sse2_exponent.c, line 335. The problem is probably line 325, where I do an aligned load, which is ok, as at line 287 I told the freaking compiler to align the static 2dim array. It seems that crappy mingw gcc compiler kurtnoise13 is using messes this up and doesn't align that array. Grrr.
Quick and dirty solution: Change the aligned load to and unaligned, ie, change _mm_load_si128 to _mm_loadu_si128.
Correct solution: fix the compiler...

I had this problem once at another place. I think gcc is somewhat brokne regarding alignment of multi dim static arrays. Seems I need to work-around this.

[Kurtnoise]

How to use Aften with pipeline through ffmpeg ?

this command line doesn't work :
FFmpeg -i input.dts -f s16le - | aften -readtoeof 1 -b 448 - output.ac3

It seems that I get an invalid header according to the stdout :
Input #0, dts, from 'E:\DVDVolume\VIDEO_TS\Audio - DTS - 5ch - DELAY -130ms.DTS
:
Duration: 00:04:01.6, start: 0.000000, bitrate: 767 kb/s
Stream #0.0: Audio: dca, 48000 Hz, 5:1, 768 kb/s
Output #0, s16le, to 'pipe:':
Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, 4608 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
invalid RIFF id in wav header
invalid wav file: -readtoeof
size= 138360kB time=246.0 bitrate=4608.0kbits/s
video:0kB audio:138360kB global headers:0kB muxing overhead 0.000000%

Any idea ?

[tebasuna51]

How to use Aften with pipeline through ffmpeg ?

It seems that I get an invalid header according to the stdout :

Any idea ?
The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.

- The raw data. How obtain a header from ffmpeg STDOUT? Or, how pass a raw PCM to Aften?

[jruggle]

The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.

- The raw data. How obtain a header from ffmpeg STDOUT? Or, how pass a raw PCM to Aften?

Reading the wav files should be fixed now in rev514. Raw input for Aften will be done eventually.

[jruggle]

The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.


As far as decoded multichannel, FFmpeg can do it. You have to use:

ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chmap to Aften for MPEG channel order.

[Kurtnoise]

The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chorder to Aften for MPEG channel order.
That could be great...:)

:thanks:

[jruggle]

The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chmap to Aften for MPEG channel order.
This problem is corrected now. You can use "-chmap 2" to remap channels from MPEG order to AC-3 order.

[tebasuna51]

As far as decoded multichannel, FFmpeg can do it. You have to use:

ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

Maybe is a problem with my ffmpeg version (built on May 13 2006 18:31:30, gcc: 4.1.0 [Sherpya]) or a Windows XP problem, but:

1) With:
ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav output.wav
I obtain a stereo mix of the input.dts

2) With:
ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

output.ac3 is not created (even stereo) with messages:
"...
invalid or empty chunk in wav header
invalid wav file: -
..."

[jruggle]

Maybe is a problem with my ffmpeg version (built on May 13 2006 18:31:30, gcc: 4.1.0 [Sherpya]) or a Windows XP problem, but:


Wow, that's a really old version. FFmpeg now has its own native DTS decoder with multichannel support. The wav header creation may have changed since then as well...I don't know. A year is a very long time when it comes to FFmpeg development. Try using the latest FFmpeg and let me know how things go.

[tebasuna51]

Wow, that's a really old version. FFmpeg now has its own native DTS decoder with multichannel support. The wav header creation may have changed since then as well...I don't know. A year is a very long time when it comes to FFmpeg development. Try using the latest FFmpeg and let me know how things go.
Thanks Justin.
With ffmpeg rev9133 and aften rev521 the command line:
FFmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften -chmap 2 - output.ac3
seems work most the times.

Maybe the dts decoder build in ffmpeg is not yet stable, because with the dts extracted (DTSParser v2.0) from this wavdts test (http://www.sr.se/laddahem/MultiKanal/Dts/SURROUNDTEST_011212.zip) crash in my system. This dts is decoded without problems with Tranzcode, NicDTSSource and foo_input_dts.

[jruggle]

Maybe the dts decoder build in ffmpeg is not yet stable, because with the dts extracted (DTSParser v2.0) from this wavdts test (http://www.sr.se/laddahem/MultiKanal/Dts/SURROUNDTEST_011212.zip) crash in my system. This dts is decoded without problems with Tranzcode, NicDTSSource and foo_input_dts.
I don't get a crash, but I do get rough audio with lots of artifacts. I get the same from dtsdec (libdca). I'll report the sample to FFmpeg's DTS maintainer.

[Kurtnoise]

@Tebasuna or somebody else who have a 5.1 surround kit : could you test this sample (http://alkasar.online.fr/Videos_FBHD/Surround Test DTS LFE- FL-SL-SR-FR-C.dts) with the command line above and tell me if you hear the LFE channel...

Thanks.

[tebasuna51]

@Tebasuna or somebody else who have a 5.1 surround kit : could you test this sample (http://alkasar.online.fr/Videos_FBHD/Surround Test DTS LFE- FL-SL-SR-FR-C.dts) with the command line above and tell me if you hear the LFE channel...

The LFE channel is mute, and is a problem from ffmpeg because:

FFmpeg -i surr_kurt.dts -ac 6 -acodec pcm_s16le -f wav output.wav

also have the LFE mute.

Decoded with Tranzcode, foo_input_ dts, NicAudio the LFE exist with sound at the beginning. The decode with NicAudio also have problems but the LFE is present.

[mltan]

Hi everyone, finally i get to post at this thread.

Anyway, thanks justin and wisodev for the replies! very much appreciated. :thanks:

Just a little background, I am currently trying to do 2 things (under the windows OS):
1. build a stand alone ac-3 encoder from ffmpeg
2. create win32 binaries of Aften on my own

Unfortunately, the documentation only has instructions for building Aften using Cmake under Linux. So I'm trying to do wisodev's way for building aften right now.

i was wondering if there are any available resources that can show a step by step guide on building win32 binaries of Aften encoder using kurtnoise way, building Cmake under Windows, or any other methods.

aften does a really good job i must say. really interesting. thanks in advance!

- mark

[Kurtnoise]

@Tebasuna : many thanks. Ok so, the problem is not on my side.

@mltan : post #301 (http://forum.doom9.org/showthread.php?p=894151#post894151)from this thread...I think it's a good start. For cvs, you can use TortoiseCVS. Very easy to use and contains an installer. Same thing for MinGW package. Anyway, you can find some doc all around the web.

[tebasuna51]

@Kurtnoise13
Bad news. Aften rev521 dont work at all (command line or pipe mode) in a Pentium Dual Core with Windows Vista Basic.

All wisodev v0.07 compiles work fine.

[Kurtnoise]

my builds do not support multithreading...:-/

[JuanC]

@Kurtnoise13
Bad news. Aften rev521 dont work at all (command line or pipe mode) in a Pentium Dual Core with Windows Vista Basic.
All wisodev v0.07 compiles work fine.
I've used Kurt's rev521 with -threads 1

It works in my c2d.

[tebasuna51]

I've used Kurt's rev521 with -threads 1

It works in my c2d.

Is true, work.

@Kurtnoise
Then, if the alternate option is a crash in MT systems, why not use -threads 1 like default instead -threads 0 (detect)?

You only need add in aften/opts.c:
...
84 opts->pad_start = 1;
85 opts->read_to_eof = 0;
86 opts->s->params.n_threads = 1;
...
At least the crash occurs only when explicitly add the -threads parameter with a value other than 1.

[Kurtnoise]

yeah, that's a workaround but I'm not really satisfied with it. I'll try something new.

Anyway, I think I should stop to build Aften right now. Wisodev's builds are more appropriate for this.

[DarkAvenger]

@tebasuna51

Does it crash? Could you be more specific or even try to debug with gdb? I would really like to get the mingw compile going instead of deactivating a feature.

[tebasuna51]

@tebasuna51

Does it crash? Could you be more specific or even try to debug with gdb? I would really like to get the mingw compile going instead of deactivating a feature.
Only can offer this:
http://img238.imageshack.us/img238/6564/aften521fz4.gif (http://imageshack.us)

And debug with gdb is chinese for me.

[gruntster]

libaften.dll (R522) crashes here everytime for me:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 816.0x2b0]
sse2_process_exponents (tctx=0x684af90)
at c:/dev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include/emmintrin.h:1028
1028 return (__m128i)__builtin_ia32_psubb128 ((__v16qi)__A, (__v16qi)__B);
(gdb) bt
#0 sse2_process_exponents (tctx=0x684af90)
at c:/dev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include/emmintrin.h:1028
#1 0x003321da in encode_frame (tctx=0x684af90, frame_buffer=0x9307f38 "")
at c:/Dev/aften/libaften/a52enc.c:1344
#2 0x00333b08 in aften_encode_frame (s=0x61a5610, frame_buffer=0x9307f38 "",
samples=0x67ed020) at c:/Dev/aften/libaften/a52enc.c:1493
#3 0x00419d43 in AUDMEncoder_Aften::getPacket (this=0x8e70030,
dest=0x9307f38 "", len=0x930ff38, samples=0x930ff3c)
at c:/Dev/avidemux_2.4_dev/avidemux/ADM_audiofilter/audioencoder_aften.cpp:150
#4 0x00525864 in defaultAudioQueueSlave (context=0x61bee80)
at c:/Dev/avidemux_2.4_dev/avidemux/ADM_toolkit/ADM_audioQueue.cpp:39
#5 0x611812fa in ptw32_threadStart@4 ()
from c:\dev\avidemux_2.4_build\pthreadGC2.dll
#6 0x780085bc in endthreadex () from C:\WINNT\system32\msvcrt.dll
#7 0x06140e20 in ?? ()
#8 0xffffffff in ?? ()
#9 0x40000060 in ?? ()
#10 0x0508e6a8 in ?? ()
#11 0x00000000 in ?? ()


Compiled using MinGW and GCC 4.2.0.

Any ideas? :confused:

Thanks.

[DarkAvenger]

Could your try to make a debugging build with -O0 -g3 and try again? Pass -DCMAKE_BUILD_TYPE=Debug along with the flags. I don't understand what is the problem with the threaded dll.

[gruntster]

I built it with CFLAGS -g3 -O0 but not CMAKE_BUILD_TYPE=Debug. I'll redo it.

Other users can use the DLL fine but it crashes on my single and dual core PCs running Windows 2000, XP & Vista.

[gruntster]

I get the same inflated filesize and same backtrace.

If I comment out the HAVE_SSE2 define in config.h and rebuild, the DLL works.

Anything else I can try?

[DarkAvenger]

It still seems gcc doesn't get the aligning right. COuld you try changing in the line with

__m128i vexp2 = _mm_load_si128((__m128i*)&exponents_blk[i]);

in file x86_sse2_exponent.c the "load" to "loadu"?

update: I just commited this, since I got sick of it. Please sync to svn and try again.

[gruntster]

Unfortunately it still crashes:


sse2_process_exponents (tctx=0x684b008)
at c:/dev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.2.0/include/emmintrin.h:695
695 *__P = __B;


The rest of the callstack (from #1) is the same as before.

I'm not that familiar with gdb. Can I set a breakpoint somewhere and step through the code to find the offending line?

update: cross-compiler build also crashes

[DarkAvenger]

??? Now I am really puzzled. When I find time, I'll try to reproduce it on the single core machine...

A quick guess: Could you change _mm_store_si128 to _mm_storeu_si128?

[gruntster]

A quick guess: Could you change _mm_store_si128 to _mm_storeu_si128?

No change :(

[DarkAvenger]

OK, I could reproduce it and I found the cause:

http://gcc.gnu.org/ml/gcc-help/2007-01/msg00231.html

Unfortunately that "fix" leads to segfault at the end, probably because the stack gets messed up and not cleaned up properly. Anybody who wants to play around getting mingw and threads going with SIMD, please have your luck.

So I am probably going to disallow threads usage on windows if compiled with mingw. msvc has no problems. Please compile using msvc, you get it for free with the express edition.

[gruntster]

Thanks for looking into it.

Aften's threads setting is set to 1 (handle->params.n_threads=1). Shouldn't this disable Aften's use of threads?

[DarkAvenger]

Where did you see that setting? I couldn't locate it.

[gruntster]

Sorry, I mean we set threads to 1 straight after calling aften_set_defaults.

I thought this would have disabled Aften's multithreading?

[DarkAvenger]

Depends, init actually detects the cpus and thus sets the number of threads, but if you set the n_threads paramter (see below) to one, aften should run single threaded.


ctx->n_threads = (ctx->params.n_threads > 0) ? s->params.n_threads : get_ncpus();
ctx->n_threads = MIN(ctx->n_threads, MAX_NUM_THREADS);

[gruntster]

I'll go with MSVC8 for the time being then.

Obviously SSE3 isn't supported but I'm guessing this probably won't impact on speed much anyway.

I've compiled it with the /MT option to remove msvcr80.dll as a dependency and everything works a treat.

Thank you for your efforts!

[jruggle]

I have restructured the audio input framework for the Aften commandline program. The major reason for this change was to support raw pcm input. The new framework will also make it easier to add support for other audio formats.

There are 3 new commandline options in rev526.

[-raw_fmt X] Raw audio input sample format (default: s16_le)
One of the pre-defined sample formats:
u8, s16_le, s16_be, s20_le, s20_be, s24_le, s24_be,
s32_le, s32_be, float_le, float_be, double_le, double_be
[-raw_sr #] Raw audio input sample rate (default: 48000)
[-raw_ch #] Raw audio input channels (default: 2)

[DarkAvenger]

I commited some stupid hack for maybe making it possible to use mingw with windows threads. Perhaps somebody wants to try it? I at least works on my single core windows machine now usng 2 threads w/o crashing.

[Kurtnoise]

Works fine here too...:)

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev531.zip






edit: slightly off-topic but...Justin, can we start to test the eac3 decoder from the FFmpeg soc project or is it too much early right now ?

[jruggle]

edit: slightly off-topic but...Justin, can we start to test the eac3 decoder from the FFmpeg soc project or is it too much early right now ?

Please do! It is definitely early, but it could be very useful. In fact, we're running into sort of a road block in that we can't find samples which use the any of the enhanced features in the specification. So the more people that test it, the more likely we are to get reports of better samples. The hope is that the sooner we get the decoder into the mainline FFmpeg repository, the better chance we have of getting good samples before the end of the summer.

edit: let me elaborate. The AC-3 specification provides a separate bitstream format for Enhanced AC-3. This bitstream format allows for some more advanced features which lead to better compression vs. quality, and also allows for higher bitrates. Well, so far, the samples we've found which use the enhanced format only take advantage of the higher bitrate. In fact, they actually use less compression features than standard AC-3 since the higher bitrate makes it less necessary. This is a problem because we can't fully test the decoder.

[honai]

In fact, they actually use less compression features than standard AC-3 since the higher bitrate makes it less necessary.

That's interesting observation. A great many HD-DVD/Blu-ray reviews claim how titles with 640kbps EAC3 audio were better sounding than "all previous formats" - including DTS at 768kbps and 1536kbps. Looks like those claim might turn out to be pure conjecture ...

[jruggle]

That's interesting observation. A great many HD-DVD/Blu-ray reviews claim how titles with 640kbps EAC3 audio were better sounding than "all previous formats" - including DTS at 768kbps and 1536kbps. Looks like those claim might turn out to be pure conjecture ...

I don't know much about the quality of DTS, but I doubt that 640kbps could sound better than 1536kbps even with all the enhanced features. This claim may very well be true though, and we just haven't been lucky enough to find the right samples.

[totya]

Hi, in #1 I read this :

For whose who prefer GUIs instead of command lines, I've made a small one.

This is immediately crashed on my Core2 system. I think this is small error, beacuse if I use aften.exe from aften-0.07-win32-bin\exe_pgo_sse3_MT, works correctly with AftenGUI ver 1.4.

Thank you, this is great audio encoder application.

[Kurtnoise]

You need Aften rev 531 or higher if you use my own builds...

[totya]

You need Aften rev 531 or higher if you use my own builds...

Possible you don't understand for me (my english is poor).

1. I downloaded "AftenGUI-1.4.zip", OK.
2. Unpack this, OK
3. Running, encoding start - crashed.

If AftenGUI-1.4.zip is bad, why available on the your www site?

4. If I change/swap aften.exe to aften-0.07-win32-bin\exe_pgo_sse3_MT\aften.exe, Aften Gui works correctly.

[Boulder]

Kurtnoise13 meant that if you use his Aften.exe builds, you need rev 531 or higher. There's nothing wrong with the GUI itself, it's aften.exe that crashed.

[totya]

Kurtnoise13 meant that if you use his Aften.exe builds, you need rev 531 or higher. There's nothing wrong with the GUI itself, it's aften.exe that crashed.

OK, I know, suggest : 1. repack 1.4 GUI (zip) without aften.exe, or 2. repack 1.4 GUI (zip) with latest aften.exe - and no problem.

This is very good encoder, and GUI too, thank you.

[Nikos]

I am a litle confused.
What is the right command line to encode 6 mono wav to AC3 5.1 with aften?
The help from aften.exe say nothing for 6 mono wav.

[Kurtnoise]

I am a litle confused.
What is the right command line to encode 6 mono wav to AC3 5.1 with aften?
The help from aften.exe say nothing for 6 mono wav.

For the moment, you can't do that directly. First, you need to create a .mux file :
C:\channelFL.wav
C:\channelC.wav
C:\channelFR.wav
C:\channelSL.wav
C:\channelSR.wav
C:\channelLFE.wav

Then, via BeSweet to create the command line :
BeSweet -core( -input myfile.mux -output myoutput.ac3 -logfile mylog.log ) -bsn( -exe aften.exe -b 448 -6chnew -chmap 1)

aften.exe and bsn.dll (http://kurtnoise.free.fr/index.php?dir=BeLight/&file=bsn_20070513.zip) are both of course required. There is probably an other way with the help of avisynth & SoundOut plugin...

[Nikos]

Thank you Kurtnoise13, now i am not confused :)

[tebasuna51]

There is probably an other way with the help of avisynth & SoundOut plugin...
To complete the Kurtnoise13 post, here the AviSynth methods necessaries for big files not supported by BeSweet.

First, you need to create a merge.avs file :
fl = WavSource("G:\channelFL.wav")
fr = WavSource("G:\channelFR.wav")
fc = WavSource("G:\channelC.wav")
lf = WavSource("G:\channelLFE.wav")
sl = WavSource("G:\channelSL.wav")
sr = WavSource("G:\channelSR.wav")
MergeChannels(fl, fr, fc, lf, sl, sr)

a) Now you can use a few methods to convert this .avs to ac3

a-1) BeHappy (http://www.box.net/shared/nkihizx1dh), a GUI method with more options like Delay, Trim, Resample, TimeStretch, ..., and other encoder options like mp4, ogg, flac, ... (.NET FrameWork v2.0 required)

a-2) BePipe, a command line tool with the syntax:
"G:\BePipe.exe" --script "Import(^G:\Merge.avs^)" | "G:\Aften.exe" -pad 0 -readtoeof 1 -b 448 - "G:\Output.ac3"
(.NET FrameWork v2.0 required)

a-3) Wavi (http://forum.doom9.org/showthread.php?p=1019016#post1019016), another command line tool, without .NET FrameWork v2.0 dependency, but slow than BePipe. The syntax:
"G:\Wavi.exe" "G:\Merge.avs" - | "G:\Aften.exe" -pad 0 -readtoeof 1 -b 448 - "G:\Output.ac3"

b) Also you can use the AviSynth plugin SoundOut (http://forum.doom9.org/showthread.php?t=120025).
Now you need add at end of Merge.avs this line:
SoundOut(output="cmd", filename="g:\Output.ac3", autoclose=true, type=0, executable="g:\aften.exe", prefilename="-pad 0 -readtoeof 1 -b 448 -")

To do the conversion you can choice between:

b-1) Open the Merge.avs with any tool with avs support, like VirtualDub. The conversion run automatically, after you can close VirtualDub.

b-2) With a command line tool like avs2avi (http://www.avs2avi.org/). The syntax:
"G:\avs2avi.exe" "G:\Merge.avs" -c null -q -e

If the last line included in the avs file is only SoundOut(), without parameters, a GUI is open to select the encoder and the parameters.

@Kurtnoise13
Your .mux have the proper order for ac3enc.dll but not for Aften if you don't use the -chmap 1 parameter.

[quantum]

@tebasuna51
Awesome instructions. Thanks for putting it together. Tested and working using the wavi method.

[Nikos]

Thanks tebasuna51 for the valuable information.

This is the wav channel mapping FL, FR, C, LFE, SL, SR.
This is the ac3 channel mapping FL, C, FR, SL, SR, LFE.
I am correct or not?
Is there any other channel mapping e.g LPCM?

One more question, which is the difference between Lt/Rt and Lo/Ro downmix preferred in -dmixmod switch?

[tebasuna51]

This is the wav channel mapping FL, FR, C, LFE, SL, SR.
This is the ac3 channel mapping FL, C, FR, SL, SR, LFE.
I am correct or not?
Yes, you are correct, this is the internal order of each format (with MicroSoft spec's for wav).
Is there any other channel mapping e.g LPCM?
I think FL, FR, C, SL, SR, LFE and big-endian format instead little-endian values.
One more question, which is the difference between Lt/Rt and Lo/Ro downmix preferred in -dmixmod switch?
From a_52b document:
"Two types of downmix should be provided: downmix to an LtRt matrix surround encoded stereo pair; and downmix to a conventional stereo signal, LoRo."

[Susana]

is there some specific program to know the bsi of an ac3 ?

I know Azid can be used, but the info is very limited; also Sonic Soft Encode can be used, with a more complete info, but is very slow importing a complete (normal) stream.

thanks

[jruggle]

Thanks tebasuna51 for the valuable information.

This is the wav channel mapping FL, FR, C, LFE, SL, SR.
This is the ac3 channel mapping FL, C, FR, SL, SR, LFE.
I am correct or not?
Is there any other channel mapping e.g LPCM?


There is also MPEG channel mapping, which is C, FL, FR, SL, SR, LFE.

Formats which use the same mappings:
WAVE and FLAC (this is also called SMPTE or ITU channel mapping)
AC-3 and Vorbis
DTS and any MPEG audio (mp2, mp3, aac, etc...)

[DarkAvenger]

I just commited changes to the SIMD detection. It is now done via compiler-independant inline assembly so that nasm and yasm won't be necessary anymore. I tested with gcc on linux, mingw on windows and msvc orcas (nmake generator). I would appreciate tests, esp with icc.

[Anima123]

jruggle:

Is psychoacoustic implementation in your recent todo list?

[HeadBangeR77]

Welcome all :)

After few months without encoding literally anything I did some transcodes of AC3 448 kbps into AC3 384 kbps, using Aften 0.7 sse build by Wisodev and the latest SoundOut 1.0.3. I must state it was damned quick, even though I've reduced the OC of my system because of the recent heat waves in Europe. Very good job, nice to discover some improvements after some time!

:thanks:

Is the latest Kurtnoise13's build (rev. 531) generic or optimized for any kind of CPUs?

EDIT: Thanks for the quick explenation, Kurtnoise13!

[Kurtnoise]

Is the latest Kurtnoise13's build (rev. 531) generic or optimized for any kind of CPUs?
Mine's optimized for MMX, SSE, SSE2, SSE3.

[ak]

I just commited changes to the SIMD detection. It is now done via compiler-independant inline assembly so that nasm and yasm won't be necessary anymore. I tested with gcc on linux, mingw on windows and msvc orcas (nmake generator). I would appreciate tests, esp with icc.
Shared lib build seems affected (x86, gcc-4.1.2), with -fPIC it breaks with:

/usr/bin/gcc -DAFTEN_BUILD_LIBRARY -Wno-switch -Wextra -Wfloat-equal -Wdisabled-optimization -pedantic -Wall -Wpointer-arith -Wredundant-decls -Wformat -Wunused -fvisibility=hidden -Wdeclaration-after-statement -Wbad-function-cast -std=gnu99 -O2 -march=athlon -mtune=athlon -fomit-frame-pointer -pipe -funroll-loops -fomit-frame-pointer -fPIC -I/tmp/aften/build -I/tmp/aften -I/tmp/aften/libaften -I/tmp/aften/aften -I/tmp/aften/pcm -I/tmp/aften/libaften/x86 -I/tmp/aften/bindings -DHAVE_CONFIG_H -DHAVE_GCC_VISIBILITY -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -o CMakeFiles/aften.dir/libaften/x86/x86_cpu_caps.o -c /tmp/aften/libaften/x86/x86_cpu_caps.c
/tmp/aften/libaften/x86/x86_cpu_caps.c: In function ‘cpu_caps_detect’
/tmp/aften/libaften/x86/x86_cpu_caps.c:53: error: PIC register ‘%ebx’ clobbered in ‘asm’

[DarkAvenger]

@ak

Thx for the report, I fixed it. Must check whether msvc it likes it, as well...

[totya]

Thank you, "AftenGUI-1.4.zip" is now correct (only GUI).

[jruggle]

jruggle:

Is psychoacoustic implementation in your recent todo list?

Yes. I actually implemented a very simple one, but it's only preliminary and not ready for inclusion yet.

[tebasuna51]

What is the right command line to encode 6 mono wav to AC3 5.1 with aften?
The help from aften.exe say nothing for 6 mono wav.

One more method to encode 6 mono wav to ac3 5.1:

CopyAudio -I "" -S "FL FR FC LF BL BR" fl.wav fr.wav fc.wav lf.wav bl.wav br.wav - | aften -readtoeof 1 - output.ac3

Where CopyAudio.exe can be obtained from AFsp-v8r2.tar.gz at Audio File Programs and Routines (http://www-mmsp.ece.mcgill.ca/Documents/Software/index.html)

-I "" is to avoid extrachunks at end of file

-S "FL FR FC LF BL BR" force WAVE_FORMAT_EXTENSIBLE header with specified channelmask. Not necessary because is aften default.

Tested with equivalent multichannel wav > 4GB.

[LigH]

BeSweet is also able to multiplex 6 mono WAV files to a 6-channel WAV. You can use BeLight as GUI, it contains a MUX file wizard. Select the preset "WAV" (or another which is the same - I think AAC) for the channel order.

I am just not sure if BeSweet can handle resulting WAV files >4 GB correctly.

...


I do remember that support for MUX files in Aften was requested for some time already.

[DarkAvenger]

I do remember that support for MUX files in Aften was requested for some time already.

Well, the source is open. Anybody can step forward with a patch.

[tebasuna51]

BeSweet is also able to multiplex 6 mono WAV files to a 6-channel WAV. You can use BeLight as GUI, it contains a MUX file wizard. Select the preset "WAV" (or another which is the same - I think AAC) for the channel order.
Yes, I say other after the Kurtnoise post (http://forum.doom9.org/showthread.php?p=1026242#post1026242) about BeSweet and the mine (http://forum.doom9.org/showthread.php?p=1026311#post1026311) about AviSynth methods.

I put this last method because don't require extra files like .mux or .avs, and can be easy implemented in GUI's

I am just not sure if BeSweet can handle resulting WAV files >4 GB correctly
Also have problems with > 2GB.

[canuckerfan]

okay... i've got a 5.1 AC3 file here which is pretty messed up. basically I want to convert it to mp3. but here's the problem... its gots some serious noise issues and all 5 channels (except of course the LFE) sound EXACTLY the same - and my ears are pretty sensitive. this is hinting me that the source was originally mono and after doing a little research i've confirmed that the source was mono and was smoshed up into a 5.1 mix. so this is the workflow that i've proposed...

1) convert the ac3 file into a 5.1 wav file. then demux one of either R, L, C, RR, LR.
2) remove noise/etc with goldwave
3) convert single wav mono file into mono mp3.

but my problem is what happens to the LFE channel? does that data get lost when I go to mp3 since I'm only working with one of the channels? any input is appreciated.

[DarkAvenger]

@canuckerfan

Did you read the topic before hijacking the thread?

[canuckerfan]

^i did read the topic. others have done the same so I thought it'd be ok. i'm sorry, my intentions weren't to hijack this thread. I will post a new thread.

[Nikos]

Thanks again tebasuna51 for the usefully suggestions.

One more question, in aften i must use -pad 0 or -pad 1?

[tebasuna51]

One more question, in aften i must use -pad 0 or -pad 1?

-pad 1 is the default -> 5.33 ms delayed like SoftEncode and others.

-pad 0 -> without delay, but with a 'fade in' in first 5.33 ms.

[Nikos]

I want to convert 6 mono wavs from a DTS-HD file to AC3 with correct Dialog Normalization value.

The whole center channel containing dialogue, sound effects and music give me RMS level -22 db with Sound Forge.

The average RMS level with Sound Forge at several places with dialogue and very little music or sound effects was -31 db.

The Sound Forge settings in the normalize window was Ignore below: -45 db and Use equal loudness contour.

Which is the correct value for the Dialog Normalization in aften?

[planet1]

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev547.zip

Could the pipe be broken :confused: :eek: :confused:

[tebasuna51]

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev547.zip

Could the pipe be broken :confused: :eek: :confused:

And also command line don't run in my XP sp1.

[Kurtnoise]

http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev547.zip

Could the pipe be broken :confused: :eek: :confused:
you have to force the raw switches for the pipeline....just like :

C:\>ffmpeg.exe -i "E:\Music\Rock el Casbah.wav" -f wav - | "C:\temp\aften.exe" -raw_fmt s16_le -raw_sr 44100 -raw_ch 2 -b 448 - "E:\Music\FFm_aften222.ac3"



@tebasuna : any error message ? if you have a multicore, try to force the threads #...

[tebasuna51]

@tebasuna : any error message ? if you have a multicore, try to force the threads #...

>aften wavex.wav z.ac3

Aften: A/52 audio encoder
Version SVN - r547
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: WAVE Signed 16-bit little-endian 48000 Hz 5.1-channel
output format: 48000 Hz 3/2 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 1

and abort. The same forcing the -threads 1
Testing with XP sp1 in Pentium 4

Maybe SSE3?

edit: Work with Pentium Dual Core and Vista

[planet1]

you have to force the raw switches for the pipeline.

Thx for the answer, for the moment I'll use Wisodev's builds with foobar2000.

[DarkAvenger]

I'd try using latest svn. I fixed some bugs in the cpu detection code which could lead to crashes.

[tebasuna51]

@Kurtnoise
Your aften_rev531 and aften_rev552 work from 0% to 100% send the 'Done!' message but never end in pipe method (Bepipe or Wavi), after a Ctrl+C to finish don't exist output file:

>bepipe --script "NicDtsSource(^blade.dts^)" | aften - zzz.ac3

Aften: A/52 audio encoder
Version SVN - r552
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

***************************************
BePipe by dimzon
***************************************
Script used:
# BEGIN
NicDtsSource("G:\Pelis\Ptes\blade.dts")
# END


Scanning for Audio Stream...
Found Audio Stream
Channels=6, BitsPerSample=16, SampleRate=48000Hz
Writing Header...
Writing Data...
Done!
^C
>

The last working rev for me is aften_rev521.

[Kurtnoise]

As I said earlier, now we need to force the raw switches for the pipeline...

bepipe --script "NicDtsSource(^blade.dts^)" | aften -raw_fmt s16_le -raw_sr 48000 -raw_ch 6 - zzz.ac3

[tebasuna51]

As I said earlier, now we need to force the raw switches for the pipeline...

Is true, I don't read the precedent post completely, only my part. Sorry.

But, what is the problem now. A new regression?

Aften always read the headers before, if all is considered raw data the headers are converted also to sound with channel async. problems.

>bepipe --script "WavSource(^z6.wav^)" | aften -raw_fmt s16_le -raw_sr 48000 -raw_ch 6 - zz6.ac3

Aften: A/52 audio encoder
Version SVN - r552
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

***************************************
BePipe by dimzon
***************************************
Script used:
# BEGIN
WavSource("z6.wav")
# END


Scanning for Audio Stream...
Found Audio Stream
Channels=6, BitsPerSample=16, SampleRate=48000Hz
Writing Header...
Writing Data...
0% input format: RAW Signed 16-bit little-endian 48000 Hz 6-channel
6-channel audio must have LFE channel
error initializing encoder
Done!

>

A perfect wav 6 chann are rejected because the 44 headers bytes is not a multiple of 12 (number of bytes per 6 chan sample).

A stereo 16 bit are converted (44 = 11 x 4) with initial click.
A stereo 32 bit (8 x ? = 44) are also rejected.

Aften can´t work now with actual BeHappy, Bepipe or Wavi.

[Kurtnoise]

But, what is the problem now. A new regression?
Dunno why actually... The only thing which might be the problem I guess, it's the raw pcm input support introducing in the revision 529.

I'll try to upload several builds tonight for testings. but I'm pretty sure it's not me that broke the code because I haven't change a lot of thing in it...:p

[tebasuna51]

I'll try to upload several builds tonight for testings. but I'm pretty sure it's not me that broke the code because I haven't change a lot of thing in it...:p

Well, I don't think you are the culprit. :)

But is easy to code, if -raw_fmt is not present the header must be read.

[DarkAvenger]

I found the bug, I will post it on the aften ml...

OK, I commited a fix - I hope so.

It is obviously wrong to activate raw mode when piping a wav. This works for me (now) in Linux:

cat in.wav |./aften - out.ac3

[Kurtnoise]

Ok...rev 661 is up for some tests.

It is obviously wrong to activate raw mode when piping a wav.
I thought that when the source had some different parameters from the default settings, raw switches were mandatory. So, I was wrong...


btw, I've a question: my PC supports as well 3DNow! & 3DNow!ext. However, these SIMD are not displayed in the frontend during encoding (only MMX...SSE3). What's wrong ?

[tebasuna51]

@Kurtnoise13, DarkAvenger
Seems rev561 work now.

Thanks

[DarkAvenger]

btw, I've a question: my PC supports as well 3DNow! & 3DNow!ext. However, these SIMD are not displayed in the frontend during encoding (only MMX...SSE3). What's wrong ?

While the cpu detection routine does detect those SIMD instruction sets, it won't get printed out, as Aften doesn't contain such code, yet.

[wisodev]

I just uploaded my R561 build (http://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924) of Aften (aften-svn-r561-vs2005.zip). This is VS2005 (but only soulution and project files used, not compiler) build but due the latest changes in Aften I was forced to use Intel C++ Compiler to be able to build Aften correctly (missing headers * pmmintrin.h * and error connected to missing headers) in Visual Studio 2005 SP1. There are no Win64 binaries included and no static libraries.

Thanks,
wisodev

[DarkAvenger]

...build but due the latest changes in Aften I was forced to use Intel C++ Compiler to be able to build Aften correctly (missing headers * pmmintrin.h * and error connected to missing headers) in Visual Studio 2005 SP1.

I don't think I changed anything there. I rather have the impression your defines are borked. Using cmake it detects that vs2005 doesn't support SSE3 and thus won't try to include pmmintrin.h. As you don't use cmake, you have to take care on your own.

BTW, Orcas has SSE3 support and I have succesfully build it with nmake generator.

[Yobbo]

Excuse please, I'm a bit confused with Aften versions!? :confused: I am using WAVtoAC3Encoder 0.4 with Aften A/52 v0.06 courtesy of Wieslaw! But I see there is Aften v0.07 now? Is there a gui for 0.07? What is the latest up-to-date? Can somebody be kind and please enough to tell me how to keep up-to-date with Aften plus gui?

Thank you! :)

[Kurtnoise]

WavtoAC3Encoder or AftenGUI both work with the last official release (0.07).

and you can use also the lastest Aften revisions with them (links are above).

[Yobbo]

well I got WavtoAC3Encoder here, which says it uses Aften 0.06. I just downloaded Wisodev's 0.07 R561 build from a few posts up... Now what do I do? Sorry to be a pain :scared:

[Kurtnoise]

Just put it the GUI folder...

[Yobbo]

What exactly do I put in the gui's folder? The whole Aften folder (there's lots of stuff in there!). Or, just the Aften.exe which is in the Win32 subfolder? And also, where exactly do I pop it? In the Gui's main folder? Or in the Win32 subfolder? Or the "ansi" sub-subfolder? Sorry again for the newb questions!

[Yobbo]

No one can help me to update my Aften gui? :(

[Kurtnoise]

If you use AftenGUI 1.4 and Aften.exe revision 561, you're up to date.

Then just put aften.exe in the same AftenGUI folder, load your files , choose a target bitrate and go !

[Yobbo]

OK thanks!! :)

[DarkNite]

I just wanted to drop in and say thank you to everybody working on Aften and AftenGUI. I appreciate it.

:thanks:

[mltan]

Hi! Just want to clarify this: " I have substituted the FFmpeg MDCT implementation with the one from libvorbis, which is faster. " - Justin @ Aftenblog

Because I found out that the one from libvorbis is based on "The use of multirate filter banks for coding of high quality digital audio" by Sporer et al. But this paper was presented a very long time ago (1992).

I am wondering why this has been chosen over other implementations and why there has been no updates since version 0.06 on this. If I am not mistaken, I think there are other more efficient methods, right?

How does it compare against other mdct implementation in terms of speed and quality, why is it "faster" then?

@wisodev and kurtnoise, i would just like to ask what you used to create the GUIs. (I am planning to create one that will operate stereo settings only)

Thank you very much!

[Kurtnoise]

mine's developped in Delphi. I would like to create a X-plateform GUI (gtk+ or something with the Aften API) but I 've a lack of time.

[wisodev]

@wisodev and kurtnoise, i would just like to ask what you used to create the GUIs. (I am planning to create one that will operate stereo settings only)

Thank you very much!

My GUI is created in Visual Studio 2005 using Visual C++. The app is based on MFC Dialog template. You can download latest source code of my app from Subversion repository (http://sourceforge.net/svn/?group_id=158644) (here you can browse online the source code (http://thefrontend.svn.sourceforge.net/viewvc/thefrontend/EncWAVtoAC3/)) or just by downloading source package (http://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726).

wisodev

[mltan]

bout the GUIs: wow, that was fast! I'll probably check out the MSVC first since its the one im using now. to kurtnoise and wisodev, :thanks:

[sl1pkn07]

sl1pkn07@SpinFlo:~/aplicaciones$ svn co https://aften.svn.sourceforge.net/svnroot/aften aften-0.07-svn
........
Revisión obtenida: 561
sl1pkn07@SpinFlo:~/aplicaciones$ cd aften-0.07-svn/
sl1pkn07@SpinFlo:~/aplicaciones/aften-0.07-svn$ cmake .
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
Please do an out-of-tree build:
rm -f CMakeCache.txt; mkdir -p default; cd default; cmake ..; make
CMake Error: in-tree-build detected
-- Configuring done
sl1pkn07@SpinFlo:~/aplicaciones/aften-0.07-svn$

use cmake version 2.4-patch 6 in Kubuntu X86_64

[Kurtnoise]

Please do an out-of-tree build:
rm -f CMakeCache.txt; mkdir -p default; cd default; cmake ..; make
it's clearly mentioned...

[sl1pkn07]

VERY LOL!

sorry ><

im supposed that script worked for me :S

[jruggle]

I am wondering why this has been chosen over other implementations and why there has been no updates since version 0.06 on this. If I am not mistaken, I think there are other more efficient methods, right?

How does it compare against other mdct implementation in terms of speed and quality, why is it "faster" then?

The main reason for using the libvorbis implementation was that the original MDCT was from FFmpeg, which was (and is still) not very fast. In fact, there is a discussion going on now at ffmpeg-devel about creating a new FFT (and hence MDCT) implementation.

Also, cpu-optimized versions of the libvorbis mdct were already out there ready to use. This wasn't part of the decision, but has been a definite advantage.

I'm sure there are faster implementations out there. At one time DarkAvenger was doing some experiments using FFTW with Aften. It was a while ago, so I don't remember if it was any faster.

[jruggle]

I just released Aften 0.0.8. Yes, I changed the version numbering. I hope it's not too confusing. I think the new versioning scheme will be easier to use. Anyway, here is the Changelog.


fixed piped input from FFmpeg
added support for MPEG channel order remapping
restructured audio input. enables raw pcm file support.
bugfixes in MMX/SSE2 code
stack align hack for x86 MinGW with threads
API changes
SIMD and threads usage is shown and is configurable
screen output gets updated every 200ms to reduce load
SIMD detection changed to compiler-independent inline assembly, thus nasm/yasm not needed anymore

[patul]

@wisodev: Any chance you would update your Wav to AC3 Encoder with this new release? :D

[wisodev]

@wisodev: Any chance you would update your Wav to AC3 Encoder with this new release? :D

Yep, I have just released new version of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) at version 0.5. You can download it from here (http://www.thefrontend.net/EncWAVtoAC3/index.html) (changelog and downloads archive (http://www.thefrontend.net/EncWAVtoAC3/download.html)).

Thanks,
wisodev

[madshi]

I just released Aften 0.0.8. Yes, I changed the version numbering. I hope it's not too confusing. I think the new versioning scheme will be easier to use. Anyway, here is the Changelog.


fixed piped input from FFmpeg
added support for MPEG channel order remapping
restructured audio input. enables raw pcm file support.
bugfixes in MMX/SSE2 code
stack align hack for x86 MinGW with threads
API changes
SIMD and threads usage is shown and is configurable
screen output gets updated every 200ms to reduce load
SIMD detection changed to compiler-independent inline assembly, thus nasm/yasm not needed anymore

Thank you. I appreciate especially the raw pcm file support. One question about this: Do you expect the same channel order in the raw pcm file as you do in the wav file? Or do you expect the Blu-Ray pcm channel order?

[jruggle]

Thank you. I appreciate especially the raw pcm file support. One question about this: Do you expect the same channel order in the raw pcm file as you do in the wav file? Or do you expect the Blu-Ray pcm channel order?
Same channel order as WAVE unless you specify the option to change it. What channel order is Blu-Ray?

[patul]

Yep, I have just released new version of WAC to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) at version 0.5. You can download it from here (http://www.thefrontend.net/EncWAVtoAC3/index.html) (changelog and downloads archive (http://www.thefrontend.net/EncWAVtoAC3/download.html)).


Wow, that was fast. Thank you..

[madshi]

What channel order is Blu-Ray?
Blu-Ray PCM channel order is this:

5.1: L, R, C, SL, SR, LFE
7.1: L, R, C, SL, BL, BR, SR, LFE

[wisodev]

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]

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

[totya]

wisodev:

Thank you!

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

[wisodev]

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]

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

I see, thx :)

[wisodev]

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]

EDIT: dumb question sorry!

[raquete]

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!

[wisodev]

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]

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]

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]

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

[wisodev]

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]

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]

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]

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]

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

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

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

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]

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]

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

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

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

if(!opts.pad_start) {

[...] // code adds padding here

}
Or am I missing/misunderstanding something?

[tebasuna51]

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]

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]

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

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

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

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]

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

Thx, commited.

@madshi

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

[jruggle]

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]

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]

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]

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]

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]

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...
The first two "encode_frame" calls always return an output length of 0. So the missing write_encoded_frame has no effect.

[madshi]

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

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]

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.

[jruggle]

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]

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]

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]

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]

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]

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]

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!! :)

[jruggle]

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

Thanks for the fix!

The segfault issue does still exist with mono input when more than 1 thread and standard zero-padding are used. Here is some gdb output.

(gdb) run sine.wav sine.ac3
Starting program: /media/hdc5/src-jbr/aften/aften-svn/build/aften sine.wav sine.ac3
[Thread debugging using libthread_db enabled]
[New Thread -1210579264 (LWP 7592)]

Aften: A/52 audio encoder
Version SVN-r569
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: WAVE Signed 16-bit little-endian 44100 Hz mono
[New Thread -1210938480 (LWP 7595)]
[New Thread -1219331184 (LWP 7596)]
output format: 44100 Hz mono (1/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2




Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219331184 (LWP 7596)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08055dc1 in encode_frame (tctx=0xb7d545ac, frame_buffer=0xb7d7ec24 "")
at /home/justin/src-jbr/aften/aften-svn/libaften/a52enc.c:1234
#2 0x08057d15 in threaded_encode (vtctx=0xb7d545ac)
at /home/justin/src-jbr/aften/aften-svn/libaften/a52enc.c:1460
#3 0xb7ec831b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7e5057e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

[DarkAvenger]

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?

I also was thinking about this, but I have to look closer whether it can be done properly (esp thinking of portability). On the other hand I think it is not the worst if the dev gets to know that he is doing something wrong. As missed samples won't be noticed immediately, but a hang does.

[DarkAvenger]

The segfault issue does still exist with mono input when more than 1 thread and standard zero-padding are used. Here is some gdb output.


I at least can't reproduce it when I use raw input. Could you mail me the sample (perhaps flac compressed)?

According to your backtrace it seems to die in the mdct. Does it work if you disable SIMD?

[Edit]OK, I found the cause and fixed it. nr and fs were 0 w/o aften having written anything to disk. Thus it exits the loop though the encoder isn't stopped yet/hasn't been flushed.

[madshi]

I also was thinking about this, but I have to look closer whether it can be done properly (esp thinking of portability). On the other hand I think it is not the worst if the dev gets to know that he is doing something wrong. As missed samples won't be noticed immediately, but a hang does.
Please try to find a way to get rid of the hang(s). I've just tried to make my Delphi libFlac implementation hang free - and it's a *major* pain in the ass. I'm not joking. The problem is that there are certain conditions where I simply want to abort the encoding. And I don't really know how to do that properly. If I don't call encode_frame often enough aften_encode_close hangs. If I call encode_frame too often, encode_frame hangs. So I don't really know a safe and never failing way to abort encoding and clean aften up without risking a hang. Except by using "-threads 1". In that case there don't seem to be any hangs. So in the end that means that multi thread encoding is currently in no fit state for me to use safely.

Thanks.

[DarkAvenger]

Please try to find a way to get rid of the hang(s). I've just tried to make my Delphi libFlac implementation hang free - and it's a *major* pain in the ass. I'm not joking. The problem is that there are certain conditions where I simply want to abort the encoding. And I don't really know how to do that properly.

Aborting is simple: Just do
while (encode_frame(..., NULL));
after that you can call the close function.

Just to be precise: Hangs can be avoided. It is a result of false usage - not a bug in aften. Of course, I know that this way the API is not entirely intuitive...

[madshi]

Aborting is simple: Just do
while (encode_frame(..., NULL));
Even this loop can result in problems. Try this in multi thread situation:

aften_encode_init(...);
aften_encode_frame(..., 1536 real samples);
while (encode_frame(..., NULL));
aften_encode_close(FContext);
I'm still getting a crash or a hang that way on my PC. Your loop solves the problem only if there are at least two aften_encode_frame calls with real samples before your loop.

Hangs can be avoided. It is a result of false usage - not a bug in aften.
aften.exe is quite simple, it's just one encoding loop and that's it. It's easy to use libAften "properly" in such a situation. But think about more complicated situations. E.g. think about a DirectShow filter. The whole encoding process is then done event based. You never know in which moment the DirectShow filter might be disconnected, aborted or destroyed. As a result you might not know exactly in which state the encoder is in that very moment.

destructor TAftenDirectShowFilter.Destroy;
begin
// what do I need to put in here?
// it needs to always work, no matter in which state the encoder is
// it also needs to work for both single and multi threading
// it also needs to work for all other combinations of options
end;

[wisodev]

@madshi

I had the same problem as you with aften termination and the trick that DarkAvenger suggested works without any problems for EncWAVtoAC3. Please check the EncWAVtoAC3 source code (http://thefrontend.svn.sourceforge.net/viewvc/thefrontend/EncWAVtoAC3/src/EncWorkThread.cpp?revision=141&view=markup) (lines 553 to 564).

[DarkAvenger]

aften_encode_init(...);
aften_encode_frame(..., 1536 real samples);
while (encode_frame(..., NULL));
aften_encode_close(FContext);
I'm still getting a crash or a hang that way on my PC. Your loop solves the problem only if there are at least two aften_encode_frame calls with real samples before your loop.


Actually I knew about this situation, but I thought you'd know the answer how to prevent it as I just wanted to give the basic idea. In fact it is the same fix I commited a few hours ago, to make it robust.



aften_encode_init(...);
got_fs_once = 0;
fs = aften_encode_frame(..., 1536 real samples);
if (fs)
got_fs_once = 1;
while (fs || !got_fs) {
fs = encode_frame(..., NULL)
if (fs)
got_fs_once = 1;
}
aften_encode_close(FContext);

The best idea is usually to use aften.c as example code and throw away stuff (while thinking hard what the code to be thrown away really does) until one gets what one wants, instead of implementing from scratch. That way you'll usually start with working code and transform it to one's needs, instead of trying to convert code into a working state.

@wisodev

No madshi is right. My example was too simple and not right for all situations (as I only noticed the flaw today). The above pseudo code should show how to make it generic. You may want to update your code.


The problem of what I see with making the API more robust (ie make it possible to call close in between) would be a lot of additional overhead in the encode path (locking-wise). Therefore I prefer a performant API, with as little locking as necessary- even if it means "slightly" more complicated use... But yes, then it should be better documented and I think I should really find the time to write an API_Usage.txt...

[madshi]

Actually I knew about this situation, but I thought you'd know the answer how to prevent it as I just wanted to give the basic idea. In fact it is the same fix I commited a few hours ago, to make it robust

[...]

The best idea is usually to use aften.c as example code and throw away (while really thinking hard what the code to be thrown away does) stuff untill one gets what one wants, instead of implementing form scratch. That way you'll usually start with working code and transform it to one's needs.
That's exactly what I did. But you missed my point about aften.c working synchronously (one big linear encoding loop), opposed to my needs of event based programming, which is quite a big difference.

How would you code the destructor of an Aften DirectShow filter? I think one solution would be to feed Aften with two dummy frames of real (zero) samples, just to be safe. And then using your "while" loop from your previous comment. Or do you have a better idea?

But you gotta admit that you make it quite hard to use Aften "properly"? :p

[DarkAvenger]

It doesn't matter whether you work in a loop or event based. You just have to take a look at the same set of state variables (in aften they are nr, fs and frame_cnt) and behave according to them. It is not rocket science, after all...

Regarding dtor: Look at my pseudo code. There fs and got_fs_once are your state variables.

Feeding Aften with dummy frames could lead to other potential problems with sync if you don't do it properly (look at the padding issue). I hope by now you understood that feeding *two* frames won't help you. It is not a constant. It depends on the number of threads.

At last, I added a text file with some notes about using the API.

[madshi]

I think I got it now. Thanks for your help!

[madshi]

I'm sorry to say but there's another hang issue with "aften_encode_close" which is not properly handled by aften.c yet. Try this:

aften_encode_init(...);
aften_encode_close(...);
It will hang in multi thread situation. This doesn't happen in aften.exe, but only because aften.exe doesn't clean up properly in error situations. Replace all those "return 1" calls with "goto end:" and aften.exe will hang, too, whenever there's any kind of error condition.

[DarkAvenger]

Right, this one is evil. :) And yes, this pattern should be allowed. I probably won't be able to fix it before the week-end, as I am busy with work. But thx for pointing this out.

[madshi]

The sample code in "API.txt" needs to be changed, too, I think. If "read_samples" returns 0, there'll be a hang.

You don't need to hurry about this. I know how to work around it. But my destructor is getting longer and longer. For giggles, here's my latest destructor code, which has now successfully passed all my tests:

destructor TAftenEncoder.Destroy;
var dummySamples : pointer;
i1 : integer;
begin
if FValid then begin
if (not FInitialized) and (FLastResult = -777) then begin
// the encoder has not been fed any real samples yet
// we need to do that, or else "aften_encode_close" will hang
GetMem(dummySamples, FBytesPerFrame);
FLastResult := aften_encode_frame(FContext, FBuf, dummySamples);
FreeMem(dummySamples);
end;

if (not FInitialized) and (FLastResult = 0) then
// encoder has not yet returned any valid AC3 frames
// but it was already fed with real PCM samples
// a call to "aften_encode_close" would hang in this situation
// so we feed the encoder with samples until we receive a valid frame
for i1 := 0 to 15 do begin
FLastResult := aften_encode_frame(FContext, FBuf, nil);
if FLastResult <> 0 then
break;
end;

while FLastResult > 0 do
// the last time the encoder was called we got a valid AC3 frame back
// when encoding is aborted there may still be AC3 frames in the queue
// a call to "aften_encode_close" would hang in this situation
// so we fetch all AC3 frames from the queue until there's nothing left
FLastResult := aften_encode_frame(FContext, FBuf, nil);

// finally we can safely close the encoder down <sigh>
aften_encode_close(FContext);
VirtualFree(FBuf, 0, MEM_RELEASE);
end;
inherited;
end;
I'm still hoping that this complicated shutdown logic will sooner or later be done internally by libAften. It would reduce my Aften related code by 30% and it would also make my code much simpler and easier to understand.

And there's another reason why I'm still not feeling well with all this destructor code: The whole destructing logic might be confused if "aften_encode_frame" keeps on returning error codes. What do I need to do in that case to properly shut aften down? Do I still need to feed the encoder until all threads are busy? Do I still need to empty the queue? If "aften_encode_frame" keeps on returning error codes, I might have to call "aften_encode_close" without ever having filled/freed the encoding queue. In that case I might again have a hang. Now I don't know in which situation exactly "aften_encode_frame" could return error codes. Maybe it will never happen (as long as there are no bugs in my code). But what do I know? Maybe if memory is short (so allocations fail) I'll have no other choice than to run into a hang because I simply can't empty the encoding queue?

[DarkAvenger]

Well, I thought I had implemented it that way that the encoder will shut the threads down, if an error had happened.but looking again, I don't think it works that way... Man, you are cruel. ;)

[Edit] Oh yes, it should work that way: On error in encoding routine, the encoder does shut down all threads, ie. if you get a negative value back from the encoder, you should be able to safely call the close function. You mustn't call the encode function after an error condition.

[madshi]

Well, I thought I had implemented it that way that the encoder will shut the threads down, if an error had happened.but looking again, I don't think it works that way... Man, you are cruel. ;)
Sorry... :D

Oh yes, it should work that way: On error in encoding routine, the encoder does shut down all threads, ie. if you get a negative value back from the encoder, you should be able to safely call the close function. You mustn't call the encode function after an error condition.
Sounds good - thanks! :)

[DarkAvenger]

I may have found an easy solution for the closing issue. Perhaps you can clean-up your dtor. Pleaser test. I haven't verified it thoroughly as I am quite tired. Furthmore error handling is missing (the close function should return, whether it was a clean close or not, ie if threads were running). And aften.c still doesn't clean up ressources thoroughly if it bails out early.

[madshi]

Thanks very much! I'll test it as soon as wisodev compiles a new build... :) Don't have Aften set up here for MSVC++ compiling on my PC. Am using libAften with Delphi...

[wisodev]

Thanks very much! I'll test it as soon as wisodev compiles a new build... :) Don't have Aften set up here for MSVC++ compiling on my PC. Am using libAften with Delphi...

Aften R573 Build uploaded:
https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=547576

[DarkAvenger]

I changed the API a bit to simplify its usage. I plan to move the padding functionality into the lib, as well. It really doesn't belong into aften.c, as lib users have to copy the code to get this feature.

[madshi]

@wisodev, thanks for the new build!

@DarkAvenger, finally got around testing your changes. On a first check everything seemed to work beautifully. Unfortunately on the very last test I got a hang again. Then it was gone. Then it came back. Then I changed the test conditions and libAften crashed during aften_encode_close (it had worked in an earlier test). So it seems to me that the shutdown is not really stable yet. It often works. Then suddenly the same test which worked before hangs or crashes again.

Wouldn't it be the safest solution to just move all the loops and checks that are currently in aften.c to aften_encode_close? Basically what you told me to do my in destructor - couldn't you do all of that in the beginning of aften_encode_close? Of course libAften would then internally need to keep track on whether aften_encode_frame was called often enough with real samples and with NULL and what the last aften_encode_frame had returned etc. But I guess that shouldn't be too hard?

Adding the pad functionality to libAften sounds like a good idea to me. I welcome any change which simplifies the API.

[DarkAvenger]

Could you be more precise of your test so I can reproduce it? Oh, and please try current svn as it contains further fixes.

[madshi]

Could you be more precise of your test so I can reproduce it?
I've tested "everything" and everything worked. Then for whatever reason I tested this again:

(1) init
(2) close

Got a hang this time. Tried it 3 times. Got hangs 3 times. Recompiled. Tried again. Hang gone. :confused:

Then I changed it to this:

(1) init
(2) one encode_frame(real samples) call
(3) close

Got a crash this time in libAften.dll. Tried it 3 times. Got 3 crashes. Recompiled. Still crash.

All of this worked perfectly fine in my first test run. So I guess reproducing it might be tricky. It's probably a timing problem.

(P.S: Might be that I confuse the 2 tests above. Maybe the first one had crashes and the 2nd hangs. Not sure...)

Oh, and please try current svn as it contains further fixes.
Ehm... wisodev? :o

[DarkAvenger]

Oh wait, I think I introduced a new bug. I'll fix it tomorrow. I suggest you wait till then.

BTW, why don't you compile aften yourself? It is not very difficult.

[madshi]

BTW, why don't you compile aften yourself? It is not very difficult.
I hate C++ and I don't have CVS access setup.

[DarkAvenger]

It is C and svn. :P Anyway, you don't have look at the code...using cmake to just compile it doesn't require a lot of skills. ;)

Anyway, I committed a hopefully now really fixed version. The big bug was quite embarassing and perfectly explains your findings: mdct buffers should be freed *after* flushing the encoder...

[wisodev]

@madshi

Aften R587 Win32 & Win64 binaries are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=548369) :)

[DarkAvenger]

So I moved the padding functionality into libaften (and also fixed aften.c to be able to encode files < 256 samples w/o padding. I didn't test this, though.) Just provide the first 256 samples in AftenContext's new member initial_samples and then no padding with zero samples happens.

[wisodev]

I have released version 0.8 of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) (sf.net shell service is offline so website was not updated).

Download

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

Changelog


- Added version check for presets configuration files when loading.
- Added check for non existing files when loading files list.
- Added load/save presets to File menu and removed Load/Save presets buttons from main window.
- Added automatic remove of successfully encoded files from files list.
- Added support in Add file dialog for raw PCM audio files (*.pcm;*.raw;*.bin).
- Added 'Reset current' button to restore all default settings for currently selected preset.
- Added possibility to change value of selected item in options list by using Right Arrow and Left Arrow keys.
- Added ToolTips for options list items.
- Fixed total progress bar reset before encoding next file.
- Fixed crush when generating batch file.
- Fixed bug in parallel file encoding mode: number of threads was set to zero when Auto was selected.
- Changed minimum supported screen resolution to 800x600 pixels.
- Added build information to about dialog.


Screenshots

http://img138.imageshack.us/img138/8197/mainwndbigpl5.th.jpg (http://img138.imageshack.us/my.php?image=mainwndbigpl5.jpg)

http://img138.imageshack.us/img138/6398/workwndbigwz2.th.jpg (http://img138.imageshack.us/my.php?image=workwndbigwz2.jpg)

http://img263.imageshack.us/img263/4343/aboutwndbiguk0.th.jpg (http://img263.imageshack.us/my.php?image=aboutwndbiguk0.jpg)

Thanks,
wisodev

[raquete]

wisodev,what is different between win32 unicode and win32 ansi?
both are working but don't know what is the right one to use.

thanks so much for new version! :)

[Adub]

one is for xp, one is for older versions of microsoft, 95,98,Me etc.

Unicode is for XP.

[raquete]

very clever,thanks so much.

[Elektra999]

Thank you very much for the Aften v0.8

Good work!! :)

[madshi]

@madshi

Aften R587 Win32 & Win64 binaries are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=548369) :)
Sorry for the late reply. Finally got around testing this one. Unfortunately it doesn't work at all for me. If I just replace the old libaften.dll with this new one, every aften_encode_frame returns "-1". Furthermore every aften_encode_frame call writes this text to stdout:

Invalid counter passed to aften_encode_frame.
I've checked "aften-types.h" to see if there's anything which has changed (remember, I'm using my own header translated to Delphi). But I didn't find any changes. With the old libaften.dll my Delphi encoder works fine, with the new one it fails. Doesn't matter if I use it in single or multi threaded mode.

Furthermore, aften_encode_close still stalls. I've done the following 1000x in a loop:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> returns "-1";
aften_encode_close;
I'm getting stalls randomly after a number of loop passes.

[wisodev]

Sorry for the late reply. Finally got around testing this one. Unfortunately it doesn't work at all for me. If I just replace the old libaften.dll with this new one, every aften_encode_frame returns "-1". Furthermore every aften_encode_frame call writes this text to stdout:

Invalid counter passed to aften_encode_frame.
I've checked "aften-types.h" to see if there's anything which has changed (remember, I'm using my own header translated to Delphi). But I didn't find any changes. With the old libaften.dll my Delphi encoder works fine, with the new one it fails. Doesn't matter if I use it in single or multi threaded mode.

Furthermore, aften_encode_close still stalls. I've done the following 1000x in a loop:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> returns "-1";
aften_encode_close;
I'm getting stalls randomly after a number of loop passes.

aften.h 0.0.8
AFTEN_API int aften_encode_frame(AftenContext *s, unsigned char *frame_buffer,
const void *samples);


aften.h r587
AFTEN_API int aften_encode_frame(AftenContext *s, unsigned char *frame_buffer,
const void *samples, int count);


Did you update you calls to aften_encode_frame? It also fails in EncWAVtoAC3 v0.8 when using with aften r587 but I didn't update my code for now (working on it :)).

[nimrodim]

I have a really noob question and would love to get some help.

I have a 5.1 channel ac3 file which i decompressed and changed the frame rate using Besweet. So now i have 6 files with the expected format of filename-(channel c\fl\fr\lfe\sr\sl).wav

Now how do i encode it back to ac3 with this program...do i have to put all 6 files in the file list or just the center channel file?

Which "Channel mapping order of input audio" do i choose, the wav(default) or ac3?

Do i have to set "Audio coding mode" and "Specify use of LFE channel" manually to what i want?

I would like to mention that i am using a Quad core processor so i have all the MMX, SSE, SSE2, SSE3 options enabled - but which engine would be best for me to use?

Thanks in advance,
Nim

[madshi]

Did you update you calls to aften_encode_frame? It also fails in EncWAVtoAC3 v0.8 when using with aften r587 but I didn't update my code for now (working on it :)).
Oooops, missed that!! I only checked for changes in the structures... :)

What meaning/purpose does that new parameter have? Is it the number of frames or the number of bytes or number of samples or something else? Or is it a first version of DarkAvenger's padding logic change ("AftenContext's new member initial_samples")?

Thanks!

[LigH]

@ nimrodin:

Unfortunately ... as far as I remember, you need to multiplex all six single-channel files into one 6-channel WAV file -- this can be done using the MUX file generator in BeLight using the WAV preset (not AC3!), and BeSweet with WAV-to-WAV "conversion"; if someone already implemented MUX file support into Aften, and I missed that, please excuse.

You will have to set the encoding mode to 3/2 + LFE.

[nimrodim]

@ nimrodin:

Unfortunately ... as far as I remember, you need to multiplex all six single-channel files into one 6-channel WAV file -- this can be done using the MUX file generator in BeLight using the WAV preset (not AC3!), and BeSweet with WAV-to-WAV "conversion"; if someone already implemented MUX file support into Aften, and I missed that, please excuse.

You will have to set the encoding mode to 3/2 + LFE.

Thanks for the reply,
As each channel is about 512mb...wouldn't there be a size limitation for the combined wav?
I could try to use Wav to Wav with the frame rate conversion in BeSweet and then plug the output file into the "WAV to AC3 Encoder".
This would bypass the need to mux the wav.

Is this possible?

[LigH]

The usual 2 GB limit (technically it would be 4 GB - 1 B, but some tools count signed numbers and fail earlier) is indeed an important issue. Therefore I can only recommend that Aften should support MUX files or a similar way to recognise a set of mono WAV files. But I am just not up-to-date if this was already implemented...

The AC3 encoder used in BeSweet has a lower quality than Aften. And Windows would always need to write a file, even if BeSweet was able to output into a pipe. It won't be possible to chain Aften and BeSweet with a pipe.

[madshi]

@nimrodim, why don't you do the whole process in one step with BeHappy? That's what I'm usually doing... BeHappy uses Aften for encoding.

[vlada]

I also realized, that BeHappy is the only really reliable transcoder for AC3/AAC/Ogg Vorbis.

[wisodev]

Oooops, missed that!! I only checked for changes in the structures... :)

What meaning/purpose does that new parameter have? Is it the number of frames or the number of bytes or number of samples or something else? Or is it a first version of DarkAvenger's padding logic change ("AftenContext's new member initial_samples")?

Thanks!

New parameter was added in revision 577 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=577). The padding was moved into libaften in revision 589 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=589).

[madshi]

New parameter was added in revision 577 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=577). The padding was moved into libaften in revision 589 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=589).
Ah, I see, that makes sense. Thank you.

[DarkAvenger]

@madshi

Yes I explained a few posts earlier that I changed the API to make it a bit easier to use. If you look at the sample you'll see I now need less variables for the same functionality.

I tested your loop and in Linux I don't have a problem with 2000 iterations - though my encode doesn't error out. I also don't know if stack gets messed up in your test, as you haven't changed your code to the new API, yet.

[madshi]

@DarkAvenger, I'm really sorry, but I have the following problems with R587:

(1) It still stalls randomly if I do this:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> succeeds;
aften_encode_close;
Try doing this 1000x in a loop. You should be able to reproduce the hang that way.

(2) If I execute the following code in a loop, about one out of 20 times libAften writes the complaint "count mustn't be 0 when passed the first time to aften_encode_frame" to stdout:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> succeeds;
while (aften_encode_frame(flush) > 0) do ;
aften_encode_close;

Adding all the security flushing loops etc back in doesn't help with R587. I'm regularly getting hangs either way, as long as I switch to multithreading mode and feed only one frame of real samples to aften.

(3) The documentation about the "count" parameter for the "aften_encode_frame" sais:

must be equal to A52_MAX_CODED_FRAME_SIZE, less than A52_MAX_CODED_FRAME_SIZE for the last frame
Does it really have to be less than A52_MAX_CODED_FRAME_SIZE for the last frame? What if the last frame happens to have exactly A52_MAX_CODED_FRAME_SIZE samples?

Sorry for being a pain in the ass and thanks for your continued work on this!!

[madshi]

Ah, our posts crossed!

Yes I explained a few posts earlier that I changed the API to make it a bit easier to use. If you look at the sample you'll see I now need less variables for the same functionality.
Yes, it's really easier. I like it.

I tested your loop and in Linux I don't have a problem with 2000 iterations
That's strange. It reliably hangs for me. But I'm not using the latest svn (of course).

[DarkAvenger]

Does it really have to be less than A52_MAX_CODED_FRAME_SIZE for the last frame? What if the last frame happens to have exactly A52_MAX_CODED_FRAME_SIZE samples?

Sorry for being a pain in the ass and thanks for your continued work on this!!

Thats is a typo and is corrected in svn. It should be A52_SAMPLES_PER_FRAME. If the last frame happens to have A52_SAMPLES_PER_FRAME, just call aften with 0 afterwords (= flushing). It should work.

I still don't know why you are getting hangs. But I also cannot properly debug on windows, which is especially bad as the locking is different. Well, I won't be having time for the next 2 weeks looking closer into the issue, as I'll be at TechEd for a week.

[madshi]

I still don't know why you are getting hangs. But I also cannot properly debug on windows, which is especially bad as the locking is different. Well, I won't be having time for the next 2 weeks looking closer into the issue, as I'll be at TechEd for a week.
I don't need this urgently. I'm still using a rather old libAften.dll with the old complicated shutdown logic. It works well without hangs. So I can wait...

[DarkAvenger]

I actually foudn a race in the windows code, which I hopefully fixed. When initing the threads, I waited in POSIX code for each thread, before initing the next one. But I didn't do this in Windows code, so maybe this could have had side effects.

[wisodev]

New version (1.0, using Aften SVN R606) of WAV to AC3 Encoder (https://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726&release_id=551344) is available for download and also updated Aften binaries (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=551340) (SVN R606) are available for download.

wisodev

[madshi]

Good news!! :)

I wasn't able to produce any problems (hangs, crashes or strange command line outputs) with wisodev's latest R606 build, anymore! Cleaned up my source, much nicer looking now!

Thanks to DarkAvenger (and wisodev).

:thanks:

[raquete]

great news wisodev,thank you and the whole team!

:thanks:

[Chumbo]

New version (1.0, using Aften SVN R606) of WAV to AC3 Encoder (https://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726&release_id=551344) is available for download and also updated Aften binaries (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=551340) (SVN R606) are available for download.

wisodev
Very much appreciated wisodev and DarkAvenger. :thanks:

[honai]

Newbie question:

I have six WAV files (FL, FR, C, SL, SR, LFE) which I intend to feed into aften or WAV to AC3 Encoder. Am I correct to assume that these two programs don't support 6 mono WAVs input?

What would the sox commandline be to remux the mono file into a single 6-channel WAV with the correct channel order so that it can be encoded by WAV to AC3 Encoder? Or if sox can't do it, what would you suggest to use for muxing the mono files?

[tebasuna51]

What would the sox commandline be to remux the mono file into a single 6-channel WAV with the correct channel order so that it can be encoded by WAV to AC3 Encoder? Or if sox can't do it, what would you suggest to use for muxing the mono files?

You can encode to ac3 directly with:
sox -M 1_FL.wav 2_FR.wav 3_C.wav 4_LFE.wav 5_SL.wav 6_SR.wav -t wav - | Aften - out6.ac3

You can use also WaveWizard (with the same order), to obtain 6-channel WAV greater than 4 GB (remember -readtoeof 1 parameter with Aften for >4 GB)

[honai]

Thanks!

[Chainmax]

Is channel coupling planned to be added in the future?

[jruggle]

Is channel coupling planned to be added in the future?
Yes. I got it working once. Now I have to get it working again after all the threading changes. And I have to find the time. But yes, eventually.

[zambelli]

New version (1.0, using Aften SVN R606) of WAV to AC3 Encoder (https://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726&release_id=551344) is available for download and also updated Aften binaries (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=551340) (SVN R606) are available for download.

I just ran into this program today after googling "WAV AC3". :) Nice work!

[jruggle]

Here is a patch for multiple mono input support in Aften. Testing and comments are welcome. It still needs a good bit of testing and cleanup before making it into SVN.

http://sourceforge.net/mailarchive/message.php?msg_name=473505AF.40105%40gmail.com

[Kurtnoise]

Thanks Justin...:)

For those who want to test it, here is a build (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_multi-mono_build1.zip).

feedbacks welcome.

[wisodev]

Here is a patch for multiple mono input support in Aften. Testing and comments are welcome. It still needs a good bit of testing and cleanup before making it into SVN.

http://sourceforge.net/mailarchive/message.php?msg_name=473505AF.40105%40gmail.com
Hi,

Test machine: AMD Athlon 64 X2 Dual Core Processor 3600+ 2.4Ghz, 3GB RAM, Microsoft Windows XP SP2

Used input files:
File:
Name: C.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: FL.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: FR.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: LFE.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: S.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: SL.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec
File:
Name: SR.wav
File Size: 514866
Format:
Type: Microsoft PCM
Channels: 1
Sample Rate: 44100 Hz
Avg bytes/sec: 88200
Block Align: 2 bytes
Bit Width: 16
Channel Mask: 0x004
Data:
Start: 44
Data Size: 514822
Samples: 257411
Playing Time: 5.84 sec

Used batch script (test-mono.cmd):
@echo on

rem TEST 3/2

aften FL.wav FR.wav C.wav LFE.wav SL.wav SR.wav -o t_32+LFE.ac3
aften -acmod 7 FL.wav FR.wav C.wav LFE.wav SL.wav SR.wav -o t_acmod7_32+LFE.ac3
aften -acmod 7 -lfe 0 FL.wav FR.wav C.wav SL.wav SR.wav -o t_acmod7_32.ac3

rem TEST 2/2

aften FL.wav FR.wav SL.wav SR.wav -o t_22.ac3
aften -acmod 6 FL.wav FR.wav SL.wav SR.wav -o t_acmod6_22.ac3

rem TEST 3/1

aften -acmod 5 -lfe 1 FL.wav FR.wav C.wav LFE.wav S.wav -o t_acmod5_31+LFE.ac3
aften -acmod 5 -lfe 0 FL.wav FR.wav C.wav S.wav -o t_acmod5_31.ac3

rem TEST 2/1

aften -acmod 4 -lfe 1 FL.wav FR.wav C.wav LFE.wav -o t_acmod4_21+LFE.ac3
aften -acmod 4 -lfe 0 FL.wav FR.wav C.wav -o t_acmod4_21.ac3

rem TEST 3/0

aften FL.wav FR.wav C.wav -o t_30.ac3
aften -acmod 3 FL.wav FR.wav C.wav -o t_acmod3_30.ac3

rem TEST 2/0

aften FL.wav FR.wav -o t_20.ac3
aften -acmod 2 FL.wav FR.wav -o t_acmod2_20.ac3

rem TEST 1/0

aften C.wav -o t_10.ac3
aften -acmod 1 C.wav -o t_acmod1_10.ac3

rem TEST 1+1

aften -acmod 0 FL.wav FR.wav -o t_acmod0_1+1.ac3

Test results:
$ test-mono.cmd

$ rem TEST 3/2

$ aften FL.wav FR.wav C.wav LFE.wav SL.wav SR.wav -o t_32+LFE.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (6 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/2 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 477.8 | bw: 38.8 | bitrate: 448.0 kbps


$ aften -acmod 7 FL.wav FR.wav C.wav LFE.wav SL.wav SR.wav -o t_acmod7_32+LFE.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (6 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/2 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 477.8 | bw: 38.8 | bitrate: 448.0 kbps


$ aften -acmod 7 -lfe 0 FL.wav FR.wav C.wav SL.wav SR.wav -o t_acmod7_32.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (5 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/2

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 480.2 | bw: 38.8 | bitrate: 448.0 kbps


$ rem TEST 2/2

$ aften FL.wav FR.wav SL.wav SR.wav -o t_22.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (4 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 2/2

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 478.8 | bw: 43.7 | bitrate: 384.0 kbps


$ aften -acmod 6 FL.wav FR.wav SL.wav SR.wav -o t_acmod6_22.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (4 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 2/2

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 478.8 | bw: 43.7 | bitrate: 384.0 kbps


$ rem TEST 3/1

$ aften -acmod 5 -lfe 1 FL.wav FR.wav C.wav LFE.wav S.wav -o t_acmod5_31+LFE.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (5 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/1 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 484.3 | bw: 43.7 | bitrate: 384.0 kbps


$ aften -acmod 5 -lfe 0 FL.wav FR.wav C.wav S.wav -o t_acmod5_31.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (4 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/1

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 479.1 | bw: 43.7 | bitrate: 384.0 kbps


$ rem TEST 2/1

$ aften -acmod 4 -lfe 1 FL.wav FR.wav C.wav LFE.wav -o t_acmod4_21+LFE.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (4 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 2/1 + LFE

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 457.9 | bw: 35.8 | bitrate: 256.0 kbps


$ aften -acmod 4 -lfe 0 FL.wav FR.wav C.wav -o t_acmod4_21.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (3 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 2/1

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 461.0 | bw: 35.8 | bitrate: 256.0 kbps


$ rem TEST 3/0

$ aften FL.wav FR.wav C.wav -o t_30.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (3 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/0

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 461.0 | bw: 35.8 | bitrate: 256.0 kbps


$ aften -acmod 3 FL.wav FR.wav C.wav -o t_acmod3_30.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (3 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz 3/0

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 461.0 | bw: 35.8 | bitrate: 256.0 kbps


$ rem TEST 2/0

$ aften FL.wav FR.wav -o t_20.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (2 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz stereo (2/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 447.7 | bw: 43.7 | bitrate: 192.0 kbps


$ aften -acmod 2 FL.wav FR.wav -o t_acmod2_20.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (2 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz stereo (2/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 447.7 | bw: 43.7 | bitrate: 192.0 kbps


$ rem TEST 1/0

$ aften C.wav -o t_10.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz mono (1/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 495.1 | bw: 43.7 | bitrate: 96.0 kbps


$ aften -acmod 1 C.wav -o t_acmod1_10.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz mono (1/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 495.1 | bw: 43.7 | bitrate: 96.0 kbps


$ rem TEST 1+1

$ aften -acmod 0 FL.wav FR.wav -o t_acmod0_1+1.ac3

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format (2 files):
WAVE Signed 16-bit little-endian 44100 Hz mono
WAVE Signed 16-bit little-endian 44100 Hz mono
output format: 44100 Hz dual mono (1+1)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2

progress: 100% | q: 466.2 | bw: 43.7 | bitrate: 192.0 kbps


$

Download used binaries (http://downloads.sourceforge.net/win32builds/aften-svn-r606-multi-mono-icl10-win32-bin.7z?use_mirror=osdn)/sources (http://downloads.sourceforge.net/win32builds/aften-svn-r606-multi-mono-icl10-src.7z?use_mirror=osdn) with multi-mono support.

Download my test results. (http://downloads.sourceforge.net/win32builds/aften-svn-r606-multi-mono-icl10-test.7z?use_mirror=osdn)

It looks like Aften with multi-mono input works without any problems on my machine.

Thanks,
wisodev

[honai]

Great, thanks!

[jruggle]

I added a new convenience parameter to the Aften commandline. You now have the option to use text to describe the channel configuration instead of -acmod and -lfe. The new parameter is -chconfig. Here is the help text for this option:
[-chconfig X] Specify channel configuration (overrides wav header)
1+1 = (Ch1,Ch2)
1/0 = (C)
2/0 = (L,R)
3/0 = (L,R,C)
2/1 = (L,R,S)
3/1 = (L,R,C,S)
2/2 = (L,R,SL,SR)
3/2 = (L,R,C,SL,SR)
adding "+LFE" indicates use of the LFE channel

example:
aften -chconfig 3/2+LFE fivepointone.wav fivepointone.ac3

[jruggle]

Here is an updated multi-mono input patch against SVN-r614.

http://sourceforge.net/mailarchive/message.php?msg_name=47365788.6010901%40gmail.com

[Yong]

hmm aften crash for me :(
i try to encode some mp3 with aften -q 240 -s 1 -w -2 %s %d(in foobar2k)
it crashed in the middle of encoding, tried wisodev and my own compile also same.
removing variable adaptive bandwidnth option avoided the crash, am i doing something stupid? :D

[DarkAvenger]

Thx for the report. This is fixed now in svn, ie. won't crash, but it is nevertheless a not supported config. Specifying -q implies vbr, and vbr and var. adap. bandw. is not supported.

[totya]

Hi all!

SVN REVISION r618 http://kurtnoise.free.fr/index.php?dir=Aften/ not working with AftenGUI on my system.
If I click encode button, immediately i get this message: "encoding finished succesfully!"
Input file is 48Khz waw file.
SVN REVISION 606 is OK (aften-svn-r606-icl10-win32-bin\aften_x86_SSE3)

Latest WAV to AC3 Encoder too not working - EncWAVtoAC3-1.0-Win32U-bin.zip
ex. I copy to dir libaftendll_x86_SSE3\libaften.dll, but application is say : "failed to load libaften".

[wisodev]

Hi all!

SVN REVISION r618 http://kurtnoise.free.fr/index.php?dir=Aften/ not working with AftenGUI on my system.
If I click encode button, immediately i get this message: "encoding finished succesfully!"
Input file is 48Khz waw file.
SVN REVISION 606 is OK (aften-svn-r606-icl10-win32-bin\aften_x86_SSE3)

Latest WAV to AC3 Encoder too not working - EncWAVtoAC3-1.0-Win32U-bin.zip
ex. I copy to dir libaftendll_x86_SSE3\libaften.dll, but application is say : "failed to load libaften".

WAV to AC3 Encoder version 1.0 uses by default aften-svn-r606-icl10-win32[win64]-bin binaries so it's strange that R606 binaries are working for you with Encoder.

The EncWAVtoAC3.win32 config file contains paths to used libaften.dll dll's. You need to edit this file if you use different libaften.dll or use it from different path.

[tebasuna51]

SVN REVISION r618 http://kurtnoise.free.fr/index.php?dir=Aften/ not working with AftenGUI on my system.
If I click encode button, immediately i get this message: "encoding finished succesfully!"

Aften r618 have a different command line syntax (to include monowav's encode):
usage: aften [options] <input.wav> [<input.wav> ...] -o <output.ac3>

Then the GUI's need be modified, be patient.

Edit: also r618 can't work with BeHappy, BeLight and syntax with Foobar need to be modified.

[totya]

Aften r618 have a different command line syntax (to include monowav's encode):
usage: aften [options] <input.wav> [<input.wav> ...] -o <output.ac3>

Then the GUI's need be modified, be patient.

Edit: also r618 can't work with BeHappy and syntax with Foobar need to be modified.

Thank you your answer!

[totya]

WAV to AC3 Encoder version 1.0 uses by default aften-svn-r606-icl10-win32[win64]-bin binaries so it's strange that R606 binaries are working for you with Encoder.

The EncWAVtoAC3.win32 config file contains paths to used libaften.dll dll's. You need to edit this file if you use different libaften.dll or use it from different path.

Sorry, this is my error, I unpack "EncWAVtoAC3-1.0-Win32U-bin.zip" without directories, and I copy dll to program dir... Sorry!

Remark: I last use 0.7version, and this version uses libaften.dll in the root program dir without directories.

[DarkAvenger]

Aften r618 have a different command line syntax (to include monowav's encode):
usage: aften [options] <input.wav> [<input.wav> ...] -o <output.ac3>

Note: It is not aften r618 we are talking about, but an experimental patched version... And the code going to be commited will probably we different and leading to a different und downward compatible syntex. So no need to "fix" the GUIs, just be a little bit patient.

[tebasuna51]

Note: It is not aften r618 we are talking about, but an experimental patched version... And the code going to be commited will probably we different and leading to a different und downward compatible syntex. So no need to "fix" the GUIs, just be a little bit patient.

Thanks DarkAvenger, I'm reading the Aften-devel mailing list and know this.
Maybe BeHappy, BeLight and Foobar don't need changes but AftenGUI and EncWavtoAc3, sure must be updated to support monowav's input long time requested by the users.

[wisodev]

Thanks DarkAvenger, I'm reading the Aften-devel mailing list and know this.
Maybe BeHappy, BeLight and Foobar don't need changes but AftenGUI and EncWavtoAc3, sure must be updated to support monowav's input long time requested by the users.

Quick update on WAV to AC3 Encoder development: the multiple mono input file support will be added as fast as the code from Justin patches gets too SVN. I have already working version of WAV to AC3 Encoder with mono input support.

Some sreenshots of the upcoming version:

http://i228.photobucket.com/albums/ee163/wisodev/1.jpg
http://i228.photobucket.com/albums/ee163/wisodev/2.jpg
http://i228.photobucket.com/albums/ee163/wisodev/3.jpg
http://i228.photobucket.com/albums/ee163/wisodev/4.jpg
http://i228.photobucket.com/albums/ee163/wisodev/5.jpg
http://i228.photobucket.com/albums/ee163/wisodev/6.jpg
http://i228.photobucket.com/albums/ee163/wisodev/7.jpg
http://i228.photobucket.com/albums/ee163/wisodev/8.jpg

Edit: Aften SVN R618 with multi mono input patch is now available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924&release_id=553973).

[jruggle]

I just fixed a critical bug caused by my typo. Please update anything based on revisions 609-619 to revision 620.

In short, the right surround channel was cut out completely.

[Kurtnoise]

revisions > 630 break encodings, right ?

A simple command like this:
aften input.wav -o output.ac3
returns "error opening input file: É♫>"

My input is a stereo wav - 44100Hz

[jruggle]

revisions > 630 break encodings, right ?

A simple command like this:
aften input.wav -o output.ac3
returns "error opening input file: É♫>"

My input is a stereo wav - 44100Hz

I'm not sure why you're having issues. Encoding works for me.

I do think you may have uncovered a bug though. "-o" is not an option in Aften unless you use one of the patches I posted for multi-mono input. I'm pretty sure current SVN is incompatible with those patches. So using "-o" should give an error. Well it seems to be doing other weird stuff for me instead of giving an error, so that's something I'll look into.

Edit: fixed in r640 to reject invalid options

[wisodev]

I've created simple MUX Wizard for WAV to AC3 Encoder incoming release with multiple mono input support. I would like to get some feedback on this option. Below is link to specially compiled executable witch is striped down version of WAV to AC3 Encoder.

Download:
http://www.sendspace.com/file/8rp7k7

Screenshot:
http://img218.imageshack.us/img218/3459/encwavtoac3muxwizard11bnz0.jpg (http://imageshack.us)

[LigH]

Nice. Looks quite close to mine I created before Kurtnoise implemented this idea into BeLight... ;)

[xbox360]

Alas after so long, I can do 6 mono wav's to AC3, yahoo ! now when will the GUI be released ? estimated time ?

Wait where is the support for 6.1 ??

[LigH]

MUX files could be generated with the MUX wizard inside BeLight for months already. It even exports with different channel orders (to make a 6-ch WAV as input for Aften, select the "WAV" order preset, not "AC3"!).

It is still some "pointless effort". Implementing MUX file support into Aften would avoid Gigabytes of temporarily used harddisk space (and minutes of transmuxing), and a risk of incomplete support of WAV files larger than 4 GB (calculate for yourself how many hours this requires, and compare to Richard Wagner operas).

[wisodev]

Nice. Looks quite close to mine I created before Kurtnoise implemented this idea into BeLight... ;)

Thnaks. Well to be true it's based on it, but I tweaked a little bit my version and this is still early preview ;)

Alas after so long, I can do 6 mono wav's to AC3, yahoo ! now when will the GUI be released ? estimated time ?

Wait where is the support for 6.1 ??

Well I have used patched Aften sources with mono input support and the WAV to AC3 Encoder is prepared to use this functionality. I'm not releasing it because mono input support in Aften is still in development and not committed into SVN.

MUX files could be generated with the MUX wizard inside BeLight for months already. It even exports with different channel orders (to make a 6-ch WAV as input for Aften, select the "WAV" order preset, not "AC3"!).

It is still some "pointless effort". Implementing MUX file support into Aften would avoid Gigabytes of temporarily used harddisk space (and minutes of transmuxing), and a risk of incomplete support of WAV files larger than 4 GB (calculate for yourself how many hours this requires, and compare to Richard Wagner operas).

Well it's not a pointless effort by any means. MUX file support is fully integrated in WAV to AC3 Encoder and no temporary WAV files are created at all!. By the way this is only preview of what will be fully integrated into WAV to AC3 Encoder. You even do not need to create MUX files. Just select proper channel config and setup mono input streams in MUX Wizard, click OK and WAV to AC3 Encoder will set automatically all options in main window. Then click Encode and mono input streams will be directly encoded into multichannel AC3 file (no temp WAV files are generated).

Thanks,
wisodev

[tebasuna51]

MUX files could be generated with the MUX wizard inside BeLight for months already. It even exports with different channel orders (to make a 6-ch WAV as input for Aften, select the "WAV" order preset, not "AC3"!).
Warning the .mux format from BeLight needed by BeSweet is plain text with quotes:
"E:\Test\FL.wav"
"E:\Test\FR.wav"
"E:\Test\C.wav"
"E:\Test\LFE.wav"
"E:\Test\SL.wav"
"E:\Test\SR.wav"

The mux file (.mux or .files) generated by EncWAVtoAC3_MUX_Wizard is in Unicode format and not compatible with BeSweet.

Also the 'Import MUX' button from EncWAVtoAC3_MUX_Wizard don't accept the .mux files generated by BeLight (with or without quotes).

@Wisodev
I think we can preserve the .mux extension for plain text BeSweet compatible format, and use .files for Unicode format.

Maybe your GUI can accept and convert the two formats.

[wisodev]

Warning the .mux format from BeLight needed by BeSweet is plain text with quotes:
"E:\Test\FL.wav"
"E:\Test\FR.wav"
"E:\Test\C.wav"
"E:\Test\LFE.wav"
"E:\Test\SL.wav"
"E:\Test\SR.wav"

The mux file (.mux or .files) generated by EncWAVtoAC3_MUX_Wizard is in Unicode format and notcompatible with BeSweet.

Also the 'Import MUX' button from EncWAVtoAC3_MUX_Wizard don't accept the .mux files generated by BeLight (with or without quotes).

@Wisodev
I think we can preserve the .mux extension for plain text BeSweet compatible format, and use .files for Unicode format.

Maybe your GUI can accept and convert the two formats.

Thanks, this are good points about .mux files. I will stick to BeSweet format for *.mux files:
1) export: ansi with quotes
2) import: with quotes and without quotes, ansi and unicode
and for *.files files:
1) export: ansi or unicode (it will depend on EncWAVtoAC3 build), without quotes
2) import: with quotes and without quotes, ansi and unicode

Note: EncWAVtoAC3_MUX_Wizard is Unicode build so obviously it supports only Unicode files.

Anyway, what should be the default format for WAV to AC3 Encoder: *.files files or *.mux files?

[xbox360]

How about .fmt ? for format.

Also can you, ahem PM me the full gui ahem ahem cough, please thank you.

[wisodev]

How about .fmt ? for format.

Also can you, ahem PM me the full gui ahem ahem cough, please thank you.

I think I will release public BETA version of WAV to AC3 Encoder with multi mono input support.

[xbox360]

Yahoo ! Im waiting...

[tebasuna51]

Anyway, what should be the default format for WAV to AC3 Encoder: *.files files or *.mux files?

I don't know if Aften go to support mux files, if so then the default format must be compatible with Aften adding only support to import ansi-BeSweet format.

If Aften don't support mux files, only sintax based in monowav's, I think we don't need another format.

BTW the conversion betwen ansi and Unicode formats are easy with Notepad.

[wisodev]

I don't know if Aften go to support mux files, if so then the default format must be compatible with Aften adding only support to import ansi-BeSweet format.

If Aften don't support mux files, only sintax based in monowav's, I think we don't need another format.

BTW the conversion betwen ansi and Unicode formats are easy with Notepad.

If Aften will support mux files than WAV to AC3 Encoder will support this format as its default.

The *.files format is simply plain list of files (including paths) so there is no need for new format :) I used the *.files files for loading and saving contents of files list.

I have no problem with conversion, it is very easy to convert text files between ansi/unicode and unicode/ansi using windows API.

[xbox360]

Aften r618 have a different command line syntax (to include monowav's encode):
usage: aften [options] <input.wav> [<input.wav> ...] -o <output.ac3>

Then the GUI's need be modified, be patient.

Edit: also r618 can't work with BeHappy, BeLight and syntax with Foobar need to be modified.

Can you provide a full working syntax sample for 6 mono wav's to 5.1 ac3 with EX mode enabled please, thank you.

[tebasuna51]

Can you provide a full working syntax sample for 6 mono wav's to 5.1 ac3 with EX mode enabled please, thank you.

- Warning 1: aften r618 from Kurtnoise was a test, the definitive syntax for multimono input isn't implemented yet in official svn releases (at least until r641 from wisodev).

- Warning 2: Dolby Surround EX encoded (-xbsi2 1 -dsurexmod 2) have sense if you have previously encoded the Back Center channel inside the Back Left, Back Right wav files.

Then, if you have the Kurtnoise r618, this work for me:
aftenK618 -xbsi2 1 -dsurexmod 2 e:\FL.wav e:\FR.wav e:\C.wav e:\LFE.wav e:\BL.wav e:\BR.wav -o e:\outEX.ac3

[DarkAvenger]

I added C# binding for Aften and would like to get some feedback. Here is a short working example, which I described in the "API C#.txt". Beware that Mono crashes, I hope 1.2.6 gets a fix, but till now I got now reaction on my report. :(


using System;
using System.IO;
using Aften;

namespace AftenTest
{
public class Test
{
public static int Main( string[] args )
{
Console.WriteLine( "Aften AC3 Encoding Demo" );
if ( args.Length != 2 ) {
Console.WriteLine(
"Usage: " + Path.GetFileNameWithoutExtension( Environment.CommandLine )
+ " <input.wav> <output.ac3>" );

return -1;
}
EncodingContext context = FrameEncoder.GetDefaultsContext();
context.Channels = 2;
context.SampleRate = 44100;
context.AudioCodingMode = AudioCodingMode.Stereo;
context.HasLfe = false;

using ( FrameEncoder encoder = new FrameEncoderInt16( ref context ) ) {
encoder.FrameEncoded += new EventHandler<FrameEventArgs>( encoder_FrameEncoded );

using ( FileStream inputStream = new FileStream( args[0], FileMode.Open ) )
using ( FileStream outputStream = new FileStream( args[1], FileMode.Create ) ) {
inputStream.Seek( 44, SeekOrigin.Begin ); // Skip WAVE header...
encoder.EncodeAndFlush( inputStream, outputStream );
}
}
Console.WriteLine( "Done" );
Console.ReadLine();
return 0;
}

private static void encoder_FrameEncoded( object sender, FrameEventArgs e )
{
if ( e.FrameNumber % 100 == 1 )
Console.WriteLine(
"Frame: " + e.FrameNumber + " Size: " + e.Size + " Quality: " + e.Status.Quality );
}
}
}

[Kurtnoise]

you want some feedback with Mono, .Net or both ?

[DarkAvenger]

Well, Mono won't work currently. I am more interested about what people think should be added to the Aften C# API or changed or whatever.

[Kurtnoise]

I'll look more carefully at the API this weekend but my first attempt with .Net doesn't seem to work either.

D:\Users\lionel\Documents\Visual Studio 2008\Projects\AftenSharp\AftenTest\bin\R
elease>AftenTest.exe "D:\Music\Rock el Casbah.wav" "D:\Music\Aften_csharp_t1
.ac3"
Aften AC3 Encoding Demo

Unhandled Exception: System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt.
at Aften.FrameEncoder.aften_encode_init(EncodingContext& context)
at Aften.FrameEncoder`1..ctor(EncodingContext& context, EncodeFrameDelegate e
ncodeFrame, ToTSampleDelegate toTSample, A52SampleFormat sampleFormat) in D:\Use
rs\lionel\Documents\Visual Studio 2008\Projects\AftenSharp\AftenSharp\FrameEncod
er.cs:line 533
at Aften.FrameEncoderInt16..ctor(EncodingContext& context) in D:\Users\lionel
\Documents\Visual Studio 2008\Projects\AftenSharp\AftenSharp\FrameEncoder.cs:lin
e 696
at AftenTest.Program.Main(String[] args) in D:\Users\lionel\Documents\Visual
Studio 2008\Projects\AftenSharp\AftenTest\Program.cs:line 30

D:\Users\lionel\Documents\Visual Studio 2008\Projects\AftenSharp\AftenTest\bin\R
elease>

compilation is fine though...

[DarkAvenger]

Hmm, which aften.dll (C library) do you have? You need a new enough svn snapshot.

[Edit] Please try to use cmake 2.5 nightly build in conjunction with Visual Studio 2008 generator (as I see you are using VS2k8) or use stable cmake with nmake generator. The generated AftenSharp.dll + aften.dll worked for me.

[Edit2] I commited a work-around for Mono. I succesfully tested the C# bindings in Linux x86_64 with Mono 1.2.6pre2.

[jruggle]

Multiple input file support is now part of Aften SVN. Below is a snippet from the commandline help that shows how to use the new options.


[-ch_X file] Add a mono file to the input list as the channel specified
These parameters are used to specify multiple mono
source files instead of a single multi-channel source
file. Only valid AC-3 combinations are allow. The
acmod, lfe, chconfig, and chmap parameters are all
ignored if multi-mono inputs are used.
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE

[tebasuna51]

Thanks Justin, is a good solution.

[wisodev]

Multiple input file support is now part of Aften SVN. Below is a snippet from the commandline help that shows how to use the new options.


[-ch_X file] Add a mono file to the input list as the channel specified
These parameters are used to specify multiple mono
source files instead of a single multi-channel source
file. Only valid AC-3 combinations are allow. The
acmod, lfe, chconfig, and chmap parameters are all
ignored if multi-mono inputs are used.
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE


Updated Aften binaries (revision 683) are available for download here (http://win32builds.sourceforge.net/aften/index.html) or here (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=558171).

[Yobbo]

Wisodev, thank you for your ongoing development!

[MacAddict]

Outstanding job on Aften and the GUI guys. Many thanks to all of you. It's amazing how fast it is on my Opteron using 2 threads!

[G_M_C]

It there an ETA for the new GUI; Especially the one with support for 6 seperate WAV's as input (" Multiple input file support ") ?

/me has a project waiting :)

[wisodev]

It there an ETA for the new GUI; Especially the one with support for 6 seperate WAV's as input (" Multiple input file support ") ?

/me has a project waiting :)

Pretty soon but I have made so many changes in the code of EncWAVtoEC3 so I need to do lot of testing. So please be patient and in few days will be released new version.

Thanks,
wisodev

[jruggle]

I need someone with better ears than me to test Aften r699 to hear for any quality changes. The audio should theoretically sound better now for the same bitrate, but my ears can't tell the difference. By the same token, VBR should theoretically give a lower bitrate and have the same quality when using the same "-q" value as compared with previous versions.

Edit: I found a sample where I can tell a slight difference. I still want lots of feedback though. :)

[G_M_C]

Im a bit confused;
When encoding DVD for DVD's, and keeping to the "official" standards; 448kbps should be max as i remember. But what bitdepth was that again ? Atm i use these settings as my rule-of-thumb;

192: 2-channel, 16 bits / 48 khz
224: 2-channel, 20 bits /48 khz
384: 5.1-channels, 16 bits / 48 khz
448: 5.1 channels, 20 bits / 48 khz

640 is also possible, although my version of DVD-lab pro doesnt seem to "work with it". I would encode that as 24 bits / 48 khz.

Are there "standards" somewhat ok ?

[nautilus7]

AC-3 doesn't understand bitdepth. These values you 're talking about don't have any meaning for it. Only bitrate and i think sample rate have a meaning.

[G_M_C]

AC-3 doesn't understand bitdepth. These values you 're talking about don't have any meaning for it. Only bitrate and i think sample rate have a meaning.

:p

That would explain why i didnt find anything about that ;)

[LigH]

Extremely simplified:

The AC-3 encoder converts the incoming samples (similar to MP3) into a frequency spectrum, and stores the (according to the psychoacustic model) most important frequency factors as floating-point values.

The less bitrate you allow, the less frequency factors can be kept as "important". A too low bitrate results in an incompletely restored frequency spectrum while decoding - so the result is rather a less accurate sound/tone (spectrum related) than a less accurate sample value (volume related).

If you allow enough bitrate, AC-3 has the potential to store even a higher resolution and dynamic than dts (in some more or less academic cases); do not expect to exhaust the AC-3 technology with integer PCM audio sources, professional audio studios are able to feed floating-point sample data.
__

The AC-3 (A/52) standard allows 640 kbps AC3. But the DVD-Video standard limits it to 448 kbps for DVD audio streams. Therefore, even some AC-3 decoders in cheap DVD players or homecinema sets are not able to decode AC-3 audio beyond 448 kbps.

[xbox360]

I AM AT A CYBER CAFE & WAITING FOR HELP, ASAP, READ ON !

Multiple input file support is now part of Aften SVN. Below is a snippet from the commandline help that shows how to use the new options.


[-ch_X file] Add a mono file to the input list as the channel specified
These parameters are used to specify multiple mono
source files instead of a single multi-channel source
file. Only valid AC-3 combinations are allow. The
acmod, lfe, chconfig, and chmap parameters are all
ignored if multi-mono inputs are used.
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE


Anyone & Everyone help me !

Can you provide a full working syntax sample for 6 mono wav's to 5.1 ac3 with EX mode enabled please, because I have created a working GUI called Aften Mono GUI. But I cant seem to workout the syntax for 6 mono wav's to 5.1 ac3.
PLEASE HELP AS SOON AS POSSIBLE !!!!!!!!

BELOW IS MY GUI SCREENSHOTS (I SWEAR & PROMISE IF YOU GUYS CAN HELP ME AS SOON AS POSSIBLE on THE SYNTAX SAMPLE, I WILL SHARE THE GUI Named Aften Mono GUI WHITH EVERYONE ON THIS PLANET EARTH !)

Stereo AC3
http://i129.photobucket.com/albums/p229/MartinJunior/StereoAC3.jpg

5.1ch AC3
http://i129.photobucket.com/albums/p229/MartinJunior/51chAC3.jpg

6.1 AC3
http://i129.photobucket.com/albums/p229/MartinJunior/61chAC3.jpg

[tebasuna51]

Can you provide a full working syntax sample for 6 mono wav's to 5.1 ac3 with EX mode enabled please, because I have created a working GUI called Aften Mono GUI. But I cant seem to workout the syntax for 6 mono wav's to 5.1 ac3.

With Wisodev aften rev683 this work for me:
aften -xbsi2 1 -dsurexmod 2 -ch_fl e:\FL.wav -ch_fr e:\FR.wav -ch_fc e:\C.wav -ch_lfe e:\LFE.wav -ch_sl e:\BL.wav -ch_sr e:\BR.wav e:\outEX.ac3

[xbox360]

With Wisodev aften rev683 this work for me:
aften -xbsi2 1 -dsurexmod 2 -ch_fl e:\FL.wav -ch_fr e:\FR.wav -ch_fc e:\C.wav -ch_lfe e:\LFE.wav -ch_sl e:\BL.wav -ch_sr e:\BR.wav e:\outEX.ac3

Is the above same as below ?

aften -xbsi2 1 -dsurexmod 2 -ch_fl D:\EncodingStuff\Audio Stuff\New Folder\audi_0.wav -ch_fc D:\EncodingStuff\Audio Stuff\New Folder\audi_2.wav -ch_fr D:\EncodingStuff\Audio Stuff\New Folder\audi_1.wav -ch_sl D:\EncodingStuff\Audio Stuff\New Folder\audi_4.wav -ch_sr D:\EncodingStuff\Audio Stuff\New Folder\audi_5.wav -ch_lfe
D:\EncodingStuff\Audio Stuff\New Folder\audi_3.wav D:\EncodingStuff\Audio Stuff\dds.ac3

Because when I use the below I get this error:

cannot mix single-input syntax and multi-input syntax

:(

[Chumbo]

Is the above same as below ?

aften -xbsi2 1 -dsurexmod 2 -ch_fl D:\EncodingStuff\Audio Stuff\New Folder\audi_0.wav -ch_fc D:\EncodingStuff\Audio Stuff\New Folder\audi_2.wav -ch_fr D:\EncodingStuff\Audio Stuff\New Folder\audi_1.wav -ch_sl D:\EncodingStuff\Audio Stuff\New Folder\audi_4.wav -ch_sr D:\EncodingStuff\Audio Stuff\New Folder\audi_5.wav -ch_lfe
D:\EncodingStuff\Audio Stuff\New Folder\audi_3.wav D:\EncodingStuff\Audio Stuff\dds.ac3

Because when I use the below I get this error:

cannot mix single-input syntax and multi-input syntax

:(
You have spaces in the path of the files. Any time the path and/or file name contains spaces, you have to put it in quotes, i.e., "D:\EncodingStuff\Audio Stuff\New Folder\audi_0.wav" rather than just D:\EncodingStuff\Audio Stuff\New Folder\audi_0.wav since the space is a command line delimiter.

I bet using this would work fine:
aften -xbsi2 1 -dsurexmod 2 -ch_fl "D:\EncodingStuff\Audio Stuff\New Folder\audi_0.wav" -ch_fc "D:\EncodingStuff\Audio Stuff\New Folder\audi_2.wav" -ch_fr "D:\EncodingStuff\Audio Stuff\New Folder\audi_1.wav" -ch_sl "D:\EncodingStuff\Audio Stuff\New Folder\audi_4.wav" -ch_sr "D:\EncodingStuff\Audio Stuff\New Folder\audi_5.wav" -ch_lfe
"D:\EncodingStuff\Audio Stuff\New Folder\audi_3.wav" "D:\EncodingStuff\Audio Stuff\dds.ac3"

[G_M_C]

Extremely simplified:

The AC-3 encoder converts the incoming samples (similar to MP3) into a frequency spectrum, and stores the (according to the psychoacustic model) most important frequency factors as floating-point values.

The less bitrate you allow, the less frequency factors can be kept as "important". A too low bitrate results in an incompletely restored frequency spectrum while decoding - so the result is rather a less accurate sound/tone (spectrum related) than a less accurate sample value (volume related).

If you allow enough bitrate, AC-3 has the potential to store even a higher resolution and dynamic than dts (in some more or less academic cases); do not expect to exhaust the AC-3 technology with integer PCM audio sources, professional audio studios are able to feed floating-point sample data.
__

The AC-3 (A/52) standard allows 640 kbps AC3. But the DVD-Video standard limits it to 448 kbps for DVD audio streams. Therefore, even some AC-3 decoders in cheap DVD players or homecinema sets are not able to decode AC-3 audio beyond 448 kbps.

:)

Thx for this abriviated explination, i understand it better now. And coming back to my original posting; I understand where these rules-of-thumb came from, it is based on the amount of info you feed the encoder related to the final bitrate.

(feed the encoder less info/less audio-detail for a lower bitrate by adapting the bitrate of the original PCM).

[G_M_C]

I get an error when using the multi-mono input;

I've used EAC3To to demux a DTS track into separate WAV's. Then i try to input those with the following commandline;

aften.exe -threads 2 -b 4 -dynrng 1 -ch_fl "d:\howl.L.wav" -ch_fc "d:\howl.C.wav" -ch_fr "d:\howl.R.wav" -ch_sl "d:\howl.SL.wav" -ch_sr "d:\howl.SR.wav" -ch_lfe "d:\howl.LFE.wav" "D:\Howl_384[PAL].AC3"

Then i get this;Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format:
WAVE Signed 24-bit little-endian 48000 Hz mono
WAVE Signed 24-bit little-endian 48000 Hz mono
WAVE Signed 24-bit little-endian 48000 Hz mono
WAVE Signed 24-bit little-endian 48000 Hz mono
WAVE Signed 24-bit little-endian 48000 Hz mono
WAVE Signed 24-bit little-endian 48000 Hz mono
output format: 48000 Hz 3/2 + LFE

invalid bitrate
error initializing encoder

I changed my commandline, and added "-raw_fmt s24_le" to it, to compensate for the bitrate;

Then i got this error;
Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

all files must be mono when using multiple input files
invalid input file(s)

And the last error isn't correct; All files are in fact mono (as Aften recognised at the first commandline.

What have I done wrong :confused:

[madshi]

I've used EAC3To to demux a DTS track into separate WAV's. Then i try to input those with the following commandline
Just wondering: If you're already using eac3to, why don't you let eac3to do the Aften encoding for you? If you want to use the latest Aften build, you can replace the "libaften.dll" that ships with eac3to with the latest version.

[DarkAvenger]

-b 4


4kps/ch is a bit too little...

[G_M_C]

4kps/ch is a bit too little...

As i understand from the long help; -b 4 means: Encode @ 384 kbps.

And why i want to use aften is that i want to verify EAC3To does the transcoding correctly; DVDLab reports an average of 383 kpbs (and not 384), and i'm under the impression that the surround mix levels are off with EAC3To (too loud, no -3 db applied i think, especially noticable when the DVD is played on a system where a downmix to stereo is needed: The center-channel/voices get mixed to faint and get " lost "). And as i said; I want to verify that by using aften directly.

[madshi]

And why i want to use aften is that i want to verify EAC3To does the transcoding correctly; DVDLab reports an average of 383 kpbs (and not 384), and i'm under the impression that the surround mix levels are off with EAC3To (too loud, no -3 db applied i think, especially noticable when the DVD is played on a system where a downmix to stereo is needed: The center-channel/voices get mixed to faint and get " lost "). And as i said; I want to verify that by using aften directly.
Oh, that's a welcome test. Please let me know if you find out that eac3to is doing something wrong. Thanks... :)

[G_M_C]

Oh, that's a welcome test. Please let me know if you find out that eac3to is doing something wrong. Thanks... :)

np i'll do that (after i get Aften to work offcourse ;) )

[wisodev]

WAV to AC3 Encoder version 1.1 is avaibale for download. (http://www.thefrontend.net/EncWAVtoAC3/index.html)

Changes:
- Updated Aften sources and libraries to svn revision 703.
- Added support for multi mono input.
- Added MUX Wizard for multi mono input.
- MUX Wizard can import *.mux and *.files file formats, Ansi and Unicode supported (*.files files fully support MUX format).
- MUX Wizard can export *.files files (Ansi or Unicode, depends on build type).
- MUX Wizard can export Ansi *.mux files using MUX file format.
- Added support read and write for *.mux files.
- Added command-line support.
- Changed presets configuration file format.
- Default and ignored preset values are not saved to file.
- Removed option to generate batch scripts.
- Ansi and Unicode configuration files are supported in all builds.

Screenshots:
http://www.thefrontend.net/EncWAVtoAC3/images/big/main_wnd-big.jpg

http://www.thefrontend.net/EncWAVtoAC3/images/big/mux_wnd-big.jpg

Thanks,
wisodev

[xbox360]

Alas wisodev releases it, wisodev showoff :angry:. What I ment was you could have released your app alot earlier you know !

[G_M_C]

WAV to AC3 Encoder version 1.1 is avaibale for download. (http://www.thefrontend.net/EncWAVtoAC3/index.html)

[...]

Thanks,
wisodev

Thx man, been waiting for this :)

Have to go to bed now, give it a try tomorrow. See if you app works on those demuxed tracks i have (posted about earlier).

[jruggle]

As i understand from the long help; -b 4 means: Encode @ 384 kbps.

I'll change the text to be a little more obvious, but if you read a little more closely you'll see that those are the defaults for different numbers of channels. If your source is 4 channels, the default bitrate will be 384 kbps.

[jruggle]

I changed my commandline, and added "-raw_fmt s24_le" to it, to compensate for the bitrate;

Then i got this error;
Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

all files must be mono when using multiple input files
invalid input file(s)

And the last error isn't correct; All files are in fact mono (as Aften recognised at the first commandline.

What have I done wrong :confused:

There are a couple things wrong. First of all, you should not specify that the input is raw if it is really wav. If you did indeed convert those files to raw, then you need to specify the raw channels and raw samplerate (if different from the default).

That said, I went ahead and changed the default number of channels for raw input to 1 instead of 2. I had been meaning to do this ever since raw input was enabled, but I just forgot about it.

[wisodev]

Alas wisodev releases it, wisodev showoff :angry:. What I ment was you could have released your app alot earlier you know !

Yes I know but it took more time to create this release because of changes I've made inside the program so I was stuck with release until now. I hope you did find my program a bit useful anyway ;)

[G_M_C]

I'll change the text to be a little more obvious, but if you read a little more closely you'll see that those are the defaults for different numbers of channels. If your source is 4 channels, the default bitrate will be 384 kbps.

I'm from Holland, so English isnt my native language. It is very much possible I havent understood the help the right way. A "more obvious" description could help out :)

[Elektra999]

Thanks for the WAVtoAC3 v1.1, Wisodev :) and for working so well.

Frank

[DarkAvenger]

I posted a highly experimental patch ("proof of concept") at aften ml which adds transcoding support to the lib. Beware that the exe has no support, yet, so it is not targeted at end-users.

[jruggle]

I have also posted a patch on aften-devel. :) It is for E-AC3 encoding. The start of the thread is here (http://sourceforge.net/mailarchive/message.php?msg_name=478AEC57.8080908%40bellsouth.net).

The latest patch can be found here (http://justin.ruggles.googlepages.com/aften_eac3_v2.diff)

[wisodev]

I have also posted a patch on aften-devel. :) It is for E-AC3 encoding. The start of the thread is here (http://sourceforge.net/mailarchive/message.php?msg_name=478AEC57.8080908%40bellsouth.net).

The latest patch can be found here (http://justin.ruggles.googlepages.com/aften_eac3_v2.diff)

Aften Win32 build using eac3_v2 patch can be found here (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924&release_id=568552).

[totya]

Aften Win32 build using eac3_v2 patch can be found here (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924&release_id=568552).

Sorry, shortly: What is "E-AC3"?

[Arite]

E-AC3 is "Dolby Digital Plus" - it is slightly improved version of A52/AC3 "Dolby Digital" (used in DVDs), and is used in Blu-ray/HD-DVDs. It is the new default mandatory audio track for those formats.

For some more information:
http://en.wikipedia.org/wiki/Dolby_Digital_Plus

Arite.

[tebasuna51]

Extended ac3 or Dolby Digital Plus (http://en.wikipedia.org/wiki/EAC3) (DD+ or E-AC-3)

- Coded bitrate: 0.032 to 6.144 Mbit/s
- Audio Channels: up to 13.1
- Sample rate: 32, 44.1, 48, or 96 kHz

[totya]

Thank you for everybody!

[Mc Onyx]

I have also posted a patch on aften-devel. :) It is for E-AC3 encoding. The start of the thread is here (http://sourceforge.net/mailarchive/message.php?msg_name=478AEC57.8080908%40bellsouth.net).

The latest patch can be found here (http://justin.ruggles.googlepages.com/aften_eac3_v2.diff)

Thanks you're the man, :) will try!
BTW Any ETA on the decoder being commited to the FFMPEG SVN?

[wisodev]

For anyone interested here are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=583753) updated Aften (http://aften.sourceforge.net/) binaries at revision 762 and here is available for download (https://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726&release_id=583773) new release of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) at version 1.2 (includes Aften R762).

Thanks,
wisodev

[nautilus7]

Thanks. Is there a changelog somewhere?

[Chumbo]

Thank you wisodev.

[Dkruskie]

Thanks wisodev

[wisodev]

Thanks. Is there a changelog somewhere?

http://www.thefrontend.net/EncWAVtoAC3/download.html

Note: This is only for WAV to AC3 Encoder.

[Boulder]

wisodev,

would you mind adding a tooltip to WAVtoAC3's multiple mono input checkbox, it would be useful to tell the correct order for the wave files for various output channel configurations.

[wisodev]

wisodev,

would you mind adding a tooltip to WAVtoAC3's multiple mono input checkbox, it would be useful to tell the correct order for the wave files for various output channel configurations.

Not a problem (actually there is already some tooltip message, but very simple). It would be helpful if someone could post here the content of this desired tooltip :)

Anyway isn't easier to use builtin MUX Wizard to set correct channel order?

[Boulder]

Anyway isn't easier to use builtin MUX Wizard to set correct channel order?Duh..I didn't notice that there is a tool for creating a mux file to use:devil: No need for a tooltip then ;)

[wisodev]

Duh..I didn't notice that there is a tool for creating a mux file to use:devil: No need for a tooltip then ;)

Note that if you use MUX Wizard it will automatically add files is correct order to main window file list and also set proper settings for you :)

[Atak_Snajpera]

I think I've found a bug in Aften used with BePipe.
It does matter if I use DirectShowSource or NicAudio in script encoded audio always finishes at 14:07 instead of 15:36. I tried older builds and still nothing :( I used AC3-Fix to check for errors and nothing again. Conversion to AAC or OGG (via BePipe) works without problems so definitely it must be something wrong with Aften.
Source: http://www.mediafire.com/?tjmo3cyyreu

[tebasuna51]

I think I've found a bug in Aften used with BePipe.

No problem here using:
bepipe --script "NicAc3Source(^casino.ac3^)" | Aften - casino2.ac3

Tested with aften 2008-03-12 and 2007-11-30.
The source is clean.

[Atak_Snajpera]

My script:


#AudioSource
LoadPlugin("C:\Users\Dawidos\Documents\Delphi_Projects\RipBot264\tools\AviSynth plugins\NicAudio\NicAudio.dll")
audio=NicAC3Source("C:\Temp\RipBot264temp\job1\job1 T80 3_2ch 448Kbps DELAY -192ms.ac3")
return audio


CMD line:
bepipe.exe --script "import(^job1.avs^)" | "aften.exe" -b 384 - "C:\Temp\RipBot264temp\audio.ac3"

[tebasuna51]

Without problem.
Maybe is a 'pipe' issue in your OS.

Try with wavi instead bepipe:
wavi.exe job1.avs - | "aften.exe" -b 384 - "C:\Temp\RipBot264temp\audio.ac3"

[Atak_Snajpera]

Do you have Vista or XP? I have Vista.

I tried with wavi and I get this
http://img74.imageshack.us/img74/5738/new2iu8.th.png (http://img74.imageshack.us/my.php?image=new2iu8.png)

[Kurtnoise]

add "-readtoeof 1" in your aften command line...

[Atak_Snajpera]

Ok It's working now but with -readtoeof 1 progress is not working :(

[tebasuna51]

Ok It's working now but with -readtoeof 1 progress is not working :(

You cheat me with the size. :cool:
Your file is 8304.448 sec (2:18:24.448) and not 15:36.

The 4GB limit for 16bit-6chan-48KHz is 2:04:16.540 then the length in wav header (only 4 bytes) is 2:18:24.448 - 2:04:16.540 = 14:07.908 and Aften stop encoding at this time.

To force Aften continue encoding disregarding the length in wav header is need -readtoeof 1, but now Aften don't know the real total length and can't show the progress.

[Atak_Snajpera]

You cheat me with the size.
I didn't have time to send whole 450 MB file :)

To force Aften continue encoding disregarding the length in wav header is need -readtoeof 1, but now Aften don't know the real total length and can't show the progress.
BePipe works again when I add -readtoeof 1 and I get progress as well (from Bepipe not from Aften).

Thanks for help guys!

[Blue_MiSfit]

Gaaagh! The sourceforge page seems to be having issues downloading the latest versions of Aften, including the super-awesome-ohmigod-cantbelieveit E-AC3 encoding build!

Does anyone have a mirror available?

~MiSfit

[NormanBates]

@Blue_MiSfit:
I have downloaded the newest eac3 experimental build (r733) for you and uploaded it. The download link is:
http://www.sendspace.com/file/i52sr1

The latest revision (r762) is here:
http://www.sendspace.com/file/g05ada

Hope this helps you.

[Blue_MiSfit]

Thanks! We should update the main OP somehow

~MiSfit

[Adub]

Uh, has development stalled on this project? I am curious, as I have gotten into ac3 encoding recently, and I know that this was THE standard for a while. Plus there were rumors of EAC3 support, so I am wondering if the author could comment. His blog hasn't been updated in months and the svn code base is for the most part several months old.

Anyone able to comment?

[jruggle]

Development is temporarily on hold, but certainly not dead. I do intend to continue development at some point. I will definitely add E-AC-3 support, and that will likely be my first focus when I have the time.

[Adub]

Excellent!! Good to hear from you jruggle and I look forward to your future work!

[ACrowley]

For anyone interested here are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=583753) updated Aften (http://aften.sourceforge.net/) binaries at revision 762 and here is available for download (https://sourceforge.net/project/showfiles.php?group_id=158644&package_id=219726&release_id=583773) new release of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) at version 1.2 (includes Aften R762).

Thanks,
wisodev

I like your Wave 2 Ac3 Gui for Aften..

2.0 is the latest Version ,right ? Is there a newer Version/updates ?

The Site "http://www.thefrontend.net/EncWAVtoAC3/" is down

[wisodev]

I like your Wave 2 Ac3 Gui for Aften..

2.0 is the latest Version ,right ? Is there a newer Version/updates ?

The Site "http://www.thefrontend.net/EncWAVtoAC3/" is down

The site will be no longer maintained! The development will be continued and there will be new releases. All the old pages are not valid any more, please use new project page : http://code.google.com/p/wavtoac3encoder/

[wisodev]

Aften binaries at revision 786 are available for download.

http://code.google.com/p/wavtoac3encoder/

[nautilus7]

Thanks a lot! Could you point where i can find a changelog?

[wisodev]

Thanks a lot! Could you point where i can find a changelog?

This is the official changelog: http://aften.svn.sourceforge.net/viewvc/aften/Changelog

[Yobbo]

Thank you Wisodev for the ongoing development of this!

I downloaded the new version of WavToAC3Encoder (2.1), but the Aften engine says R762. I downloaded the new binaries (R786), so do I just pop the new libaften.dll's into the WavToAC3Encoder subfolders to replace the old libaftens??

Actually I already did this but WavToAC3Encoder still says "R762"?

How do I keep this the most up-to-date please?

Thanks again! (I use it a lot!).

[wisodev]

Thank you Wisodev for the ongoing development of this!

I downloaded the new version of WavToAC3Encoder (2.1), but the Aften engine says R762. I downloaded the new binaries (R786), so do I just pop the new libaften.dll's into the WavToAC3Encoder subfolders to replace the old libaftens??

Actually I already did this but WavToAC3Encoder still says "R762"?

How do I keep this the most up-to-date please?

Thanks again! (I use it a lot!).
Well it should work with this version of Aften, if you want to see new version number in main window of program you should edit configuration files manually as I do when updating Aften libraries (depending on release these settings are located in file: EncWAVtoAC3.win32 or EncWAVtoAC3.win64).

Example for win32 release:
Aften R786=libaftendll_x86\libaften.dll
Aften R786 SSE=libaftendll_x86_SSE\libaften.dll
Aften R786 SSE2=libaftendll_x86_SSE2\libaften.dll
Aften R786 SSE3=libaftendll_x86_SSE3\libaften.dll
PS. As far I know there where some changes in functionality between this releases so please be careful and test before doing any work. I will update GUI to include this changes, so for now it is recommend to use Aften R762.

[ACrowley]

ive a question about DD EX encoding. The Back Center Channel is greyed out/not avaibele In your Mux Wizard?
Is it possible to unlock the Back Center Channel for 6.1 (Matrix encoded ofcourse) DD EX encoding ?

[tebasuna51]

ive a question about DD EX encoding. The Back Center Channel is greyed out/not avaibele In your Mux Wizard?
Is it possible to unlock the Back Center Channel for 6.1 (Matrix encoded ofcourse) DD EX encoding ?

Aften can't encode 7 channels (6.1) if you see the channel config the max channels are 5.1
When you select 3/1 the SL-SR are greyed and appear the S
(only 1 surround channel).

If you have 3 surround channels and previously matrix the SC in SL and SR you can use Aften to encode and set the flag in header:
'Dolby Surround EX mode' to 'Dolby Surround EX encoded'

I think you can use Sox to matrix the SC in SL-SR:

sox -m -v 0.5858 SL.wav -v 0.4141 SC.wav new-SL.wav
sox -m -v 0.5858 SR.wav -v 0.4141 SC.wav new-SR.wav

[madshi]

I think you can use Sox to matrix the SC in SL-SR:

sox -m -v 0.5858 SL.wav -v 0.4141 SC.wav new-SL.wav
sox -m -v 0.5858 SR.wav -v 0.4141 SC.wav new-SR.wav
Don't you need to apply a phase shift for matrixing?

[tebasuna51]

Don't you need to apply a phase shift for matrixing?

I think is not necesary.

In dpl downmix the FC channel is mixed (and recovered) with FL-FR without phase shift.

The phase shift can be necesary in dpl if FL and SL (and FR with SR) are dependent and the mix between can produce problems.

BTW, you can test using:
sox -m -v 0.5858 SL.wav -v 0.4141 SC.wav new-SL.wav
sox -m -v -0.5858 SR.wav -v 0.4141 SC.wav new-SR.wav

[ACrowley]

Aften can't encode 7 channels (6.1) if you see the channel config the max channels are 5.1
When you select 3/1 the SL-SR are greyed and appear the S
(only 1 surround channel).

If you have 3 surround channels and previously matrix the SC in SL and SR you can use Aften to encode and set the flag in header:
'Dolby Surround EX mode' to 'Dolby Surround EX encoded'

I think you can use Sox to matrix the SC in SL-SR:

sox -m -v 0.5858 SL.wav -v 0.4141 SC.wav new-SL.wav
sox -m -v 0.5858 SR.wav -v 0.4141 SC.wav new-SR.wav

Ok, thx. However, i use AAC or dts es 6.1 discrete to reencode 7Ch Tracks.
But its the same Problem.. we have no (100%) proper Method to decode DD EX to 6.1/7ch waves ,also not for dts.
But this is the aften encoder thread ......:)

By the Way : Ive tested wave2ac3 2.1 x264 with rev786 SSE3Wow! The Perfomance is great. ~30% faster compared with DD Encoder Pro v7
The Quality is "fully" identical to the off. Dolby Digital Encoder Pro v7. Maybe i will switch to Aften instead of DD Enc Pro 7 from SonyVegas 8. Aften has no disadvantage

[wisodev]

By the Way : Ive tested wave2ac3 2.1 x264 with rev786 SSE3Wow! The Perfomance is great. ~30% faster compared with DD Encoder Pro v7
The Quality is "fully" identical to the off. Dolby Digital Encoder Pro v7. Maybe i will switch to Aften instead of DD Enc Pro 7 from SonyVegas 8. Aften has no disadvantage

Did you try Aften on multi-core CPU? Aften is even faster with that kind of systems!

Tip:
To get even more performance set the:
"Fast bit allocation" to "Faster encoding"
and
"Fast exponent strategy decision" to "Faster encoding"

there is probably some quality impact with these settings.

[ACrowley]

Did you try Aften on multi-core CPU? Aften is even faster with that kind of systems!

Tip:
To get even more performance set the:
"Fast bit allocation" to "Faster encoding"
and
"Fast exponent strategy decision" to "Faster encoding"

there is probably some quality impact with these settings.

Im encoding on a quadcore !6600 @ 3.2ghz..
No, i dont use FastBitAllocation/FastEx.Startegiy.D.....Its fast enough.

[menlvd]

why encoding (wavtoac3) don't work with latest build 826 and 786
get - [2008-11-06, 20:43:48.828] Encoder Error: Failed to initialize encoder.

[wisodev]

why encoding (wavtoac3) don't work with latest build 826 and 786
get - [2008-11-06, 20:43:48.828] Encoder Error: Failed to initialize encoder.

Please read this post: http://forum.doom9.org/showthread.php?p=1207826#post1207826

[raquete]

wisodev, thanks so much for the news!

[wisodev]

WAV to AC3 Encoder version 2.2 was released (changelog (http://wavtoac3encoder.googlecode.com/svn/trunk/doc/Changes.txt)).

Aften Win32 and x64 binaries svn revision 832 where released.

Download all from here. (http://code.google.com/p/wavtoac3encoder/)

[Yobbo]

:thanks:

[raquete]

thank you wisodev. :)

[wisodev]

WAV to AC3 Encoder version 2.3 is available for download (http://code.google.com/p/wavtoac3encoder/) (changes (http://wavtoac3encoder.googlecode.com/svn/trunk/doc/Changes.txt)).

[totya]

WAV to AC3 Encoder version 2.3 is available for download (http://code.google.com/p/wavtoac3encoder/) (changes (http://wavtoac3encoder.googlecode.com/svn/trunk/doc/Changes.txt)).

Thanks!

[Boulder]

Is there a changelog regarding the various Aften SVN builds after v0.0.8?

[wisodev]

Is there a changelog regarding the various Aften SVN builds after v0.0.8?

http://aften.svn.sourceforge.net/viewvc/*checkout*/aften/Changelog

for changes after 0.08 please check point "version SVN : current"

i don't think there is changelog for each SVN build, you may try checking same revision of Changelog

[Boulder]

Thanks :)

[raquete]

wisodev,
thanks so much one more time, wav2ac3enc stills champion!

[TFM_TheMask]

What does the new mode of operation mean. And specific what does Transcoding do?

[jruggle]

What does the new mode of operation mean. And specific what does Transcoding do?
What exactly are you referring to?

Transcoding would be AC3-to-AC3, with essentially a decode/re-encode. Aften is setup to be able to handle this in the future, but does not currently do so. The main obstacle is that the decoder that would be used is currently under GPL. If/when it is ever relicensed to LGPL then it will be ported over to Aften from FFmpeg.

[wisodev]

I have been working on Avisynth scripts support in WAV to AC3 Encoder, finally I have added some preliminary support for .avs scripts. Please find attached the version 3.0 BETA 1 of WAV to AC3 Encoder, it really needs a lot of testing before final release.

Changes in v3.0 BETA 1:
- Added preliminary Avisynth (*.avs files) scripting support (not supported in 'Multiple mono input' and in 'One per file' mode).
- Added *.avs filter to open dialog.
- Double-click on *.avs script in files list to show AVS File Properties window.

DOWNLOAD: WAV to AC3 Encoder 3.0 BETA 1 (http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-3.0_BETA_1-Win32-bin.zip)

[TFM_TheMask]

What exactly are you referring to?

Transcoding would be AC3-to-AC3, with essentially a decode/re-encode. Aften is setup to be able to handle this in the future, but does not currently do so. The main obstacle is that the decoder that would be used is currently under GPL. If/when it is ever relicensed to LGPL then it will be ported over to Aften from FFmpeg.

Ok :thanks:. I also saw in the todo list that you want to implement an upmix feature. Is this something that is coming soon or not? Maybe you can take a look at the upmix feature of the AC3Filter (DirectShow).

[jruggle]

Ok :thanks:. I also saw in the todo list that you want to implement an upmix feature. Is this something that is coming soon or not? Maybe you can take a look at the upmix feature of the AC3Filter (DirectShow).
I'm sorry, but it's not high on my priority list. The highest priority for Aften is improving the core encoder, which mostly involves channel coupling, better bit allocation, and improved DRC. After that, it's E-AC3, so unless I suddenly find myself with massive amounts of free time or some volunteer developers, it likely will be some time before I get to the less important items on the list.

[Boulder]

How's the development going on regarding those important items?

[TFM_TheMask]

I'm sorry, but it's not high on my priority list. The highest priority for Aften is improving the core encoder, which mostly involves channel coupling, better bit allocation, and improved DRC. After that, it's E-AC3, so unless I suddenly find myself with massive amounts of free time or some volunteer developers, it likely will be some time before I get to the less important items on the list.

Then for the time being I'll stick to Ac3Filter. Keep up the good work.:thanks:

[madshi]

I'm not using the latest build, so maybe it has been fixed in the meanwhile, but maybe you Aften guys can double check?

If I encode a 44.1khz AC3 file, the framesize toggles between two different values. So far, so good. The frames with the smaller framesize are fully correct. However, the frames with the bigger framesize have an incorrect 2nd CRC (the first CRC is correct), as far as I can say. Both delaycut and eac3to don't like the 44.1khz files created by Aften because of this problem.

Could you please check that?

(I've tried both 448kbps and 640kbps, 5.1 channels).

[jruggle]

I'm not using the latest build, so maybe it has been fixed in the meanwhile, but maybe you Aften guys can double check?

If I encode a 44.1khz AC3 file, the framesize toggles between two different values. So far, so good. The frames with the smaller framesize are fully correct. However, the frames with the bigger framesize have an incorrect 2nd CRC (the first CRC is correct), as far as I can say. Both delaycut and eac3to don't like the 44.1khz files created by Aften because of this problem.

Could you please check that?

(I've tried both 448kbps and 640kbps, 5.1 channels).
I can't duplicate the problem with the latest build, but I don't have delaycut or eac3to. liba52 and libavcodec both check the CRCs and they aren't having any problems with a 44.1kHz 5.1-ch file I just made. Could you check again with the latest version from SVN?

[madshi]

I can't duplicate the problem with the latest build, but I don't have delaycut or eac3to. liba52 and libavcodec both check the CRCs and they aren't having any problems with a 44.1kHz 5.1-ch file I just made. Could you check again with the latest version from SVN?
Edit: I've just checked with wisodev's "WAV to AC3 Encoder 3.0 BETA 1" and the problem doesn't occur with that one. So I guess it's fixed in SVN. I'll update to the latest SVN next week.

Thanks!

[nautilus7]

I'll update to the latest SVN next week.At last! :p

[gizzin]

How's the development going on regarding those important items?

I'm curious myself :)

[jruggle]

How's the development going on regarding those important items?
I have channel coupling working locally, but it's basically just on or off with fixed parameters. Using coupling in the variable bandwidth mode will be my ultimate goal for bit allocation. And I at least have a somewhat detailed plan:

A table can be created, similar to the bandwidth bits table, in order to estimate the total number of bits for a given coupling setting. Here is an outline for how it could work:

Set bit allocation map at target quality/bitrate setting.

mantissa/exp bit estimate for each fbw bin up to target bandwidth for all channels/blocks
mantissa/exp bit estimate for each coupling band up to target bandwidth for coupling channel/all blocks
overhead bit estimate for adding coupling params
bit estimates for coupling coordinates

Start bit count at full target bandwidth w/o coupling. If it fits, goto 12.
Enable coupling

start band = min(target-1, 15)
end band = target
coord blocks = 6

Incrementally decrease start band down to target-5 while frame is still too large. If it fits, goto 12.
Reset start/end bands. Change coord blocks to match exponent strategy. If it fits, goto 12.
Incrementally decrease start band down to target-5 while frame is still too large. If it fits, goto 12.
Reset start/end bands. Change coord blocks to 1. If it fits, goto 12.
Incrementally decrease start band down to zero while frame is still too large. If it fits, goto 12.
If bandwidth priority is selected, goto 12. If quality priority is
selected, continue to step 10.
Incrementally decrease end band down to 3 while frame is still too large. If it fits, goto 12.
Turn off coupling. Set bwcode to target and incrementally decrease bwcode down to zero while frame is still too large. (current vbw mode)
Always reencode in CBR mode with final settings to get the final result.


I think the toughest part to get right about this will be the bandwidth/quality tradeoff since bandwidth also affects the overall sound quality.

As for improving DRC... I know what I need to look into (attack/decay rates), but I haven't started to do so yet. It also presents difficulties with threaded encoding which I have to explore more thoroughly.

[me7]

Is it possible to use a dts file as input without decoding it to multiple wav files first?

[Boulder]

eac3to should help you out.

[wisodev]

Is it possible to use a dts file as input without decoding it to multiple wav files first?

WAV to AC3 Encoder version 3.0 supports Avisynth scripts as input so you can decode dts using Avisynth without decoding to wav files first.

[madshi]

Does anybody (maybe Justin?) happen to know the "official" way on how a discrete 6.1 source should be mixed/prepared for AC3 EX encoding?

As far as I understand, Dolby always wants a 90° shift in the surround channels. But what about the back center? I guess it should be lowered in volume by 3db, right? But should it also be phase shifted by 90° or by something else?

Thanks!!

[carlmart]

I need to convert a DTS file to AC3. A tutorial I find needs Aften to work with Foobar 2000.

Where and how should install Aften within Foobar so that it recognizes it? There's an Aften directory I put within Foobar, but it doesn't seem to see it.

[Boulder]

If you can't get it to work, you could use eac3to for easier processing, see the appropriate thread in this forum.

[carlmart]

If you can't get it to work, you could use eac3to for easier processing, see the appropriate thread in this forum.

Can it convert DTS to AC3 or it works along with Foobar or any other?

[tebasuna51]

I need to convert a DTS file to AC3. A tutorial I find needs Aften to work with Foobar 2000.

Where and how should install Aften within Foobar so that it recognizes it? There's an Aften directory I put within Foobar, but it doesn't seem to see it.

You can put Aften.exe anywhere you like.
After you need configure Aften in Foobar, File -> Preferences -> Converter -> Add New, and fill this screen:

http://img248.imageshack.us/img248/4668/vifooaftenpl1.png (http://imageshack.us)

Edit: or other parameters, only -readtoeof 1 is recommended always

[sneaker_ger]

I have a problem opening avs files in WavToAC3Encode 3.0: it just throws an error message at me: "failed to initialize avisynth". Then the program crashes. This happens with all avs files and the files are working fine in other apps. What can I do?
Avisynth 2.5.8 and Windows XP SP3

[wisodev]

I have a problem opening avs files in WavToAC3Encode 3.0: it just throws an error message at me: "failed to initialize avisynth". Then the program crashes. This happens with all avs files and the files are working fine in other apps. What can I do?
Avisynth 2.5.8 and Windows XP SP3

Try Avisynth version 2.5.7 because version 2.5.8 had some changes that cause my program to crash.

[sneaker_ger]

Ok, thanks. Have you fixed the problems for your next release? Don't really feel like downgrading right now.

[wisodev]

Ok, thanks. Have you fixed the problems for your next release? Don't really feel like downgrading right now.

Not planned any time soon.

[zn]

"WAV to AC3 Encoder" was removed from Google Code?

http://code.google.com/p/wavtoac3encoder/

[wisodev]

"WAV to AC3 Encoder" was removed from Google Code?

http://code.google.com/p/wavtoac3encoder/

WAV to AC3 Encoder is back at Google Code.

New version 4.0 was released today.

Downloads:
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.0.exe
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.0.zip

Screenshots:
http://img528.imageshack.us/img528/3323/engineswnd.th.png (http://img528.imageshack.us/i/engineswnd.png/)
http://img33.imageshack.us/img33/9595/mainwnd.th.png (http://img33.imageshack.us/i/mainwnd.png/)
http://img30.imageshack.us/img30/6342/muxwnd.th.png (http://img30.imageshack.us/i/muxwnd.png/)
http://img22.imageshack.us/img22/8781/workwnd.th.png (http://img22.imageshack.us/i/workwnd.png/)

[tebasuna51]

Thanks wisodev

[MrVideo]

I've not read all of the pages of this thread, as it would take way too long.

I've looked at the command line options, but do not see anything that would allow 6 mono WAV files to AC3 encoding. Obviously it is capable of doing that, since the wave to ac3 encoder GUI front end can set up Aften for AC3 encoding of mono wave files.

Just what are the magic command line options to aften to get it to use 6 mono wave files and map those files for the correct channel location?

Thanks.

[tebasuna51]

Just what are the magic command line options to aften to get it to use 6 mono wave files and map those files for the correct channel location?
From aften -longhelp
[-ch_X file] Add a mono file to the input list as the channel specified
These parameters are used to specify multiple mono
source files instead of a single multi-channel source
file. Only valid AC-3 combinations are allowed. The
acmod, lfe, chconfig, and chmap parameters are all
ignored if multi-mono inputs are used.
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE
Here is the situation. I have a transport stream that has three MPEG-2 audio streams that comprise the 6 channels for AC3 encoding. They map as follows:

1) L/R
2) C/LFE
3) LS/RS

How do I tell eac3to to use those three dual channel streams as input to aften AC3 encoding?

If you have AviSynth with NicAudio.dll plugin you can use an avs file like this for input to EncWavToAc3 (Aften GUI):

fr = NicMPG123Source("File_lr.mp2")
cl = NicMPG123Source("File_cl.mp2")
su = NicMPG123Source("File_su.mp2")
mergechannels(fr,cl,su)

[MrVideo]

From aften -longhelp
[-ch_X file] Add a mono file to the input list as the channel specified
These parameters are used to specify multiple mono
source files instead of a single multi-channel source
file. Only valid AC-3 combinations are allowed. The
acmod, lfe, chconfig, and chmap parameters are all
ignored if multi-mono inputs are used.
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE

I just placed the wisodev built SSE3 x86 version on my system and ran the -longhelp option and the -ch_X option does not exist.

[tebasuna51]

I just placed the wisodev built SSE3 x86 version on my system and ran the -longhelp option and the -ch_X option does not exist.
Also with short help (SSE3 x86 version r843):
D:\Internet>aften -h

Aften: A/52 audio encoder
Version SVN
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

usage: aften [options] <input.wav> <output.ac3>
options:
...
[-ch_X file] Add a mono file to the input list as the channel specified
ch_fl = Front Left
ch_fc = Front Center
ch_fr = Front Right
ch_sl = Surround Left
ch_s = Surround
ch_sr = Surround Right
ch_m1 = Dual Mono Channel 1
ch_m2 = Dual Mono Channel 2
ch_lfe = LFE

[raquete]

wisodev,

in win2000 is not working, the program don't open and show advice about 'kernell32.dll".

versions 2.3 or older are still working very fine, can you help please with version 4.0?

thanks!

[MrVideo]

Aften: A/52 audio encoder
Version SVN

Therein lies the potential problem. The -ch_X option must be new to the SVN development tree, as it is not in the 0.0.8 release that I have.

And no, I cannot compile. I do enough Unix compiling ar work, that I just want to run programs at home.

Is there a way to get the binary of the aften version that does support -ch_X?

[wisodev]

wisodev,

in win2000 is not working, the program don't open and show advice about 'kernell32.dll".

versions 2.3 or older are still working very fine, can you help please with version 4.0?

thanks!

Probably because I'm using the new Visual Studio 2010 to build my app and it might happen that compatibility with windows 2k was broken.

I'm running it without a problems under Windows XP SP3 and Windows 7 RC.

[tebasuna51]

Therein lies the potential problem. The -ch_X option must be new to the SVN development tree, as it is not in the 0.0.8 release that I have.

Multiple input file support is quite old (30th November 2007):
http://forum.doom9.org/showthread.php?p=1071074#post1071074

Is there a way to get the binary of the aften version that does support -ch_X?
You have the last wisodev versions here:
http://code.google.com/p/wavtoac3encoder/downloads/list

[MrVideo]

Multiple input file support is quite old (30th November 2007):

Ah, which is after the 0.0.8 release.

You have the last wisodev versions here:

The link I found only pointed to the released versions. Maybe that link should be placed into the sticky post #1 and marked as development versions.

I think I ran across that link, but thought it was only for wisodev's GUI program, not also aften itself.

Thanks, though. I installed it and now the option does indeed show up.

[raquete]

WAV to AC3 Encoder version 3.0 supports Avisynth scripts as input so you can decode dts using Avisynth without decoding to wav files first.

i have all WAV to AC3 Encoder versions from 0.1 to the last new 4.0, less 3.0....don't know why i don't got before, i don't saw.:stupid:
XP is too heavy to run in my old pc.
as 4.0 don't work in win2000, do you still have the 3.0 version somewhere to download ?

thank you!

[wisodev]

i have all WAV to AC3 Encoder versions from 0.1 to the last new 4.0, less 3.0....don't know why i don't got before, i don't saw.:stupid:
XP is too heavy to run in my old pc.
as 4.0 don't work in win2000, do you still have the 3.0 version somewhere to download ?

thank you!

http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-3.0-Win32-bin.zip

[raquete]

wisodev, you're not only a great developer, you're a fast gentleman too! :)

:thanks: so much, 3.0 is working perfectly in win2000!

[wisodev]

wisodev,

in win2000 is not working, the program don't open and show advice about 'kernell32.dll".

versions 2.3 or older are still working very fine, can you help please with version 4.0?

thanks!

Version 4.1 was released and I've fixed compatibility issue with Windows 2000.

Downloads:
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.1.exe
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.1.zip

[raquete]

Version 4.1 was released and I've fixed compatibility issue with Windows 2000.

Downloads:
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.1.exe
http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-4.1.zip

:helpful: thanks again wisodev, you're very nice as always!
new version working in win2k. :thanks:

[raquete]

wisodev,
EncWAVtoAC3-4.1 crash when i hit "encode".
version 3.0 with Aften R832 works fine.

can be the Aften R843 version? :confused:

[sneaker_ger]

Version 4.1 still crashes shortly after dropping an AviSynth script: "Failed to initialize AviSynth". I'm on Windows XP SP3 and AviSynth 2.5.8.

[wisodev]

Version 4.1 still crashes shortly after dropping an AviSynth script: "Failed to initialize AviSynth". I'm on Windows XP SP3 and AviSynth 2.5.8.

WAV to AC3 Encoder does not work correctly with AviSynth version 2.5.8, but it should work with version 2.5.7 or below.

[wisodev]

wisodev,
EncWAVtoAC3-4.1 crash when i hit "encode".
version 3.0 with Aften R832 works fine.

can be the Aften R843 version? :confused:

Do you have log file from EncWAVtoAC3-4.1 ?

[raquete]

wisodev,
only a "advice" with (from portuguese to english):
"unknow software exception (0xc000001d) in 0x0107868c
Click OK to close the program
Click Cancel to depurate the program"

if i click OK close the program, clicking Cancel give advice telling that will create the error log but i can't find this log.
searching the last files modified in the pc could not find too.

what is the complete name of the log file?

[wisodev]

wisodev,
only a "advice" with (from portuguese to english):
"unknow software exception (0xc000001d) in 0x0107868c
Click OK to close the program
Click Cancel to depurate the program"

if i click OK close the program, clicking Cancel give advice telling that will create the error log but i can't find this log.
searching the last files modified in the pc could not find too.

what is the complete name of the log file?

In program folder you should find file named "EncWAVtoAC3.log"

[raquete]

In program folder you should find file named "EncWAVtoAC3.log"
the path to the log file was adjusted to the folder of source files to encode.
was not found in the path adjusted or in the EncWAVtoAC3 folder.(searching in all hds, not found) :(

edit: the program crash right after hit "encode" and don't create log i think.

[raquete]

loading 24b/96K files in EncWAVtoAC3 and adjusting "Sample rate" to 96K i encoded and got noises(hiss) result and have more than double size comparing when i feed with 24b/48k.

have a way to feed with 24b/96K and get 24b/48K ?

[tebasuna51]

loading 24b/96K files in EncWAVtoAC3 and adjusting "Sample rate" to 96K i encoded and got noises(hiss) result and have more than double size comparing when i feed with 24b/48k.

have a way to feed with 24b/96K and get 24b/48K ?
Standard Ac3 don't support 96KHz, first you need to resample to 48KHz.

You can use BeHappy, eac3to, sox|aften, ...

[raquete]

Standard Ac3 don't support 96KHz, first you need to resample to 48KHz.

You can use BeHappy, eac3to, sox|aften, ...

yes, i understand and i did bad question.
i mean: i want to load 24/96 waves in EncWAVtoAC3 and get 24/48 AC3.
is possible without downsample the waves first?

[tebasuna51]

i mean: i want to load 24/96 waves in EncWAVtoAC3 and get 24/48 AC3.
is possible without downsample the waves first?
I never tried, but you have the proof. Seems don't work.

But EncWavToAc3 accept .avs files you can use the ssrc(48000) from AviSynth.

[raquete]

I never tried, but you have the proof. Seems don't work.

But EncWavToAc3 accept .avs files you can use the ssrc(48000) from AviSynth.

it's a great surprise, living and learning.

encoding DTS from 24/96 waves with DTS Pro Encoder:
(from LeeAudBi logs)
" Extension Audio Descr. Flag 2 : Frequency Extension (X96k)
Extended Coding Flag 1 : Yes"
sounds a little better than with 24/48 waves using surcode:
"Extension Audio Descr. Flag 0 : Channel Extension (XCh)
Extended Coding Flag 0 : Not"

now is not needed to downsample the waves to encode AC3, the .avs is the solution, will be faster, use less hd space, etc.

thank you very much!

[raquete]

wisodev,
EncWAVtoAC3-4.1 crash when i hit "encode".
version 3.0 with Aften R832 works fine.

can be the Aften R843 version? :confused:

wisodev

after invert all libaftendll_x86(library) between EncWAVtoAC3-3.0 and EncWAVtoAC3-4.1, 3.0 crash and 4.1 now is running fine with Aften R832.
then the "problem" must be in Aften R843 version!

(why i don't did it before?!? )

EncWAVtoAC3-4.1 running with Aften R832
http://img40.imageshack.us/img40/3367/ewtac341.jpg

http://img40.imageshack.us/img40/3367/ewtac341.th.jpg (http://img40.imageshack.us/i/ewtac341.jpg/)

cheers! :)

[wisodev]

wisodev

after invert all libaftendll_x86(library) between EncWAVtoAC3-3.0 and EncWAVtoAC3-4.1, 3.0 crash and 4.1 now is running fine with Aften R832.
then the "problem" must be in Aften R843 version!

(why i don't did it before?!? )

EncWAVtoAC3-4.1 running with Aften R832
http://img40.imageshack.us/img40/3367/ewtac341.jpg

http://img40.imageshack.us/img40/3367/ewtac341.th.jpg (http://img40.imageshack.us/i/ewtac341.jpg/)

cheers! :)

Looks like new Aften build has problem with older CPUs (as I see on screenshot you have some older CPU). Probably I have turned by mistake some optimizations for Aften builds as I am using new version of Intel C++ compiler and Intel has made plenty of changes in compiler optimization options.

[raquete]

wisodev, you're right.
i'm using duron 1.8 :o ...but i have athlon XP2000+ too :p
i'm doing one championship to test what is worse...lol
in the end both are too old and slow. :scared:

[OAKside]

wisodev, you're right.
i'm using duron 1.8 :o ...but i have athlon XP2000+ too :p
i'm doing one championship to test what is worse...lol
in the end both are too old and slow. :scared:
I also noticed erratic behavior from R843 (SSE3). (CPU: Athlon 64 X2 4200, circa 2004.) I contacted raquete for R832 (thanks!),
since I couldn't seem to find downloads of Aften builds very easily, esp. the full Windows binaries packages.

Any chance of hosting an older Aften build (perhaps R832 x86 Binaries) at the WAV to AC3 Encoder Google Code downloads (http://code.google.com/p/wavtoac3encoder/downloads/list) page? :)

[Midzuki]

OAKside wrote:
I contacted raquete for R832 (thanks!),
since I couldn't seem to find downloads of Aften builds very easily, esp. the full Windows binaries packages.

Any chance of hosting an older Aften build (perhaps R832 x86 Binaries) at the WAV to AC3 Encoder Google Code downloads page?

@ http://ftp.heanet.ie/disk1/sourceforge/w/project/wi/win32builds/ ,

one can find "aften -r762" and older builds, but not the -r832 one. :(
It would be interesting to know why it was (apparently at least) "wiped out of the map". :confused:

[wisodev]

I also noticed erratic behavior from R843 (SSE3). (CPU: Athlon 64 X2 4200, circa 2004.) I contacted raquete for R832 (thanks!),
since I couldn't seem to find downloads of Aften builds very easily, esp. the full Windows binaries packages.

Any chance of hosting an older Aften build (perhaps R832 x86 Binaries) at the WAV to AC3 Encoder Google Code downloads (http://code.google.com/p/wavtoac3encoder/downloads/list) page? :)

OAKside wrote:


@ http://ftp.heanet.ie/disk1/sourceforge/w/project/wi/win32builds/ ,

one can find "aften -r762" and older builds, but not the -r832 one. :(
It would be interesting to know why it was (apparently at least) "wiped out of the map". :confused:

Please just download version 3.0 of WAV to AC3 Encoder and copy included Aften R832 .dll's to new version of program.

Download link: http://wavtoac3encoder.googlecode.com/files/EncWAVtoAC3-3.0-Win32-bin.zip

PS. If you need this old release I have re-uploaded it to project Download page (http://code.google.com/p/wavtoac3encoder/downloads/list?can=4&q=&colspec=Filename+Summary+Uploaded+Size+DownloadCount), but marked downloads as 'Deprecated'.

[OAKside]

PS. If you need this old release I have re-uploaded it to project Download page (http://code.google.com/p/wavtoac3encoder/downloads/list?can=4&q=&colspec=Filename+Summary+Uploaded+Size+DownloadCount), but marked downloads as 'Deprecated'.Perfect, I appreciate it wisodev. :thanks:

[raquete]

OAKside,
what i upload for you was EncWAVtoAC3-4.1 with Aften R832 and works perfectly, right? (or not? )

now is ok as wisodev reupload "everything" but i'm curious about what i send for you.

wisodev
when and if you have time, can you do a "how to" explaining each parameter of advanced mode/options and advanced options in EncWAVtoAC3?
(for boreds users like me :p)
thanks.

[tebasuna51]

@raquete
First read the help in Aften:

aften -longhelp

and after ask your specific questions, because explain all the options is very hard.

Edit:
Full a52 document:
http://www.atsc.org/standards/a_52b.pdf