Aften 0.0.8 is out

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