HeadAC3he does work with --alt preset "number"

[DarkAvenger]

BTW, I found out that the hacked dll indeed works with HeadAC3he to a certain extent:

6. Very High Quality (q=0) = remains as originally UNLESS VBR Method VBR-ABR is selected. If VBR-ABR is selected, then --alt-preset nnn (ie. --alt preset ABR) is performed for ABR bitrates between 80kbps and 320kbps. With ABR selected, all other switches are non-functional.

As I selecet the q=0 profile as base profile, ABR with hacked dll will just be --alt-preset "number", as stated above.

So, as movies usually are done for low-bitrates, and for that abr is recommended, I can now recommend to use HeadAC3he with Lame_enc.dll (hacked) in ABR mode (and only ABR mode). This should be esp. interesting for tangent: As I said in the other thread, LAme_enc will take care of scaling, you don't need to hassle, as everything is lossless (except the compresion of course :D).

[omol]

Yup, the alt-preset dll works flawlessly as I have been using it for couple of days. They could be found here (http://www.inf.ufpr.br/~rja00/). DA, regarding your excellent HeadAC3he, is it possible to implement direct transcoding to mp3 without creating intermediate wav file? I don't like the slowness of BeSweet...;)

ps. being as a long time DSEnc user, I would like to thank you for another excellent prog.

regards
omol

[DarkAvenger]

The problem is, if you want speed, you need temp HD space (float mode) if you want no temp hd space, it will be slow (dumb mode, works like BeSweet). Or you need about 2-3GIGs of rAM, and then it would be possible as well... ;)

[DSPguru]

Originally posted by omol
DA, regarding your excellent HeadAC3he, is it possible to implement direct transcoding to mp3 without creating intermediate wav file? I don't like the slowness of BeSweet...;)
BeSweet isn't slow - it's fast. HeadAC3he is faster.
now, you can't have it all - both speed & minimum temp space. BeSweet is about no-intermediate-file, HeadAC3he is about speed.

and another point,
Whenever (if DA decides to go in that direction) HeadAC3he will offer ALL the features BeSweet does, it won't be as fast as it is now.

HeadAC3he is the fastest two-pass AC3 decoder. BeSweet is a full-featureable Audio format transcoder.
Each proggy is better for a different purpose.

[DarkAvenger]

Basically everything said is true.

BeSweet is about no-intermediate-file, HeadAC3he is about speed

You have the option in HeadAC3he to have maximum speed or no temp files usage, as well. I think it is always better to have the choice.


Whenever (if DA decides to go in that direction) HeadAC3he will offer ALL the features BeSweet does, it won't be as fast as it is now.


True, as well. It is natural that everything will slow down a few %, if a lot of stuff is integrated into a program. But HeadAC3he's speed comes from the buffering, so it will *always* be faster then BeSweet, using identical dlls, unless DG puts effort into making a good buffering, as well. Nevertheless, DG doesn't make it easy to be speedy with trying to keep away the ssrc.dll sources, as right now it is not optimal for buffered use. I hope he changes his mind, or I just misunderstood his intentions.

I will probably never offer that amount of feature as BeSweet has, since I don't have time for it (and putting new stuff in while using a multithreaded buffering is way harder), esp as Dg is too fast coding for me to keep up...

HeadAC3he is the fastest two-pass AC3 decoder

Not completely true, as it can do a lot more than this. :D


So it is a good choice to use either of the named programs, HeadAC3he or BeSweet. Just a matter of personal preference.

[omol]

Originally posted by DarkAvenger
The problem is, if you want speed, you need temp HD space (float mode) if you want no temp hd space, it will be slow (dumb mode, works like BeSweet). Or you need about 2-3GIGs of rAM, and then it would be possible as well... ;)

But is there any kind of piping mechanism just like those on UNIX? i.e., pipe the output of the 1st process to the stdin of another process? The reason I ask this is that I don't know much about how Win32 OS works, but on any kind of UNIX, it doesn't have much speed penalty but will save a lot of temp hd space. Also, another suggestion, if HeadAC3he could have an option to select this encoder (http://member.nifty.ne.jp/~pen/free/gogo3/mct_gogo.htm), HeadAC3he will truely be a speed daemon....:D

regards,
omol

[DarkAvenger]

But is there any kind of piping mechanism just like those on UNIX?

not exactly, but it won't help though. HeadAC3he *is* the fastest possible way (with or without temp space).

About gogo: Is there a .dll of it? But you'll have to sacrifice some quality for speed, which might not be a good option.

[omol]

Originally posted by DarkAvenger


not exactly, but it won't help though. HeadAC3he *is* the fastest possible way (with or without temp space).

About gogo: Is there a .dll of it? But you'll have to sacrifice some quality for speed, which might not be a good option.

Yes, there's a .dll version of Gogo308 alpha, that's based on Lame 3.88 as far as I understand. Try mitiok's page (http://home.pi.be/~mk442837/) then scroll down to "some audio related programs" section. The gogo308alpha.zip (http://home.pi.be/~mk442837/gogo308alpha.zip) indeed comes with an exe as well as dll, though documentation is lacking. The dll works in CDex (http://www.cdex.n3.net/), so I guess the dll interface is the same as the old gogo verion 2. The quality is not as good as --alt-preset of the latest Lame3.91, sounds very Japan-ish (if you happen to have any chance to listen to any Japanese album then you will know what I mean). But for target bit rate around 128kbps, the quality is quite ok. It does act like Lame's ABR mode even it's VBR in gogo.

regards,
omol

[DarkAvenger]

Without docs - no go. I manged to compile the exe and dll on my own, but the interface is not lame compatible...

But I read in Lame's todo that they want to integrate the fast assembly parts into Lame, so it will just be a matter of time, when quality will just be faster. ;) In the meanwhile I wouldn't be to sad about Gogo.

[DarkAvenger]

If you have trouble getting the alt setting to work, check out following, which MaTTeR pointed out:

"When the users DL the package, it contains 3 DLLs, DLL1 through 3. DLL3 should be the one that they use. The read me file with the DLL will walk them through the settings."