Aften 0.0.8 is out

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