New winLAME test version (aac, wma, flac, multichannel & more)

[DeXT]

Hi there. Yesterday I released a winLAME test version I've been playing with in the past weeks. It adds a bunch of new supported formats as well as enhanced multichannel transcoding support, specially focused on Vorbis & AAC. It also adds WAV-float & 24 bit output for you audiophiles

Of course I also updated every included library to the latest available stable version, including faad 2.0, faac 1.24, mad 0.15.1b & lame 3.96. I included a non-ICL vorbis 1.0.1 compile because I don't want to redistribute intel's libmmd.dll but you can use the ones available at RareWares if you wish, including the new aoTuV. That's the magic of dynamic link libraries

Here's the post at Hydrogenaudio with more details and download links:

http://www.hydrogenaudio.org/index.php?showtopic=22143&

Hope you like it.

DeXT

[Kurtnoise]

DeXT could you post a direct link for this tool ?

HA is regulary down for me...

Thanks

[DSP8000]

winlame-test_040601

DSP8000

[hans-jürgen]

Originally posted by DeXT
Of course I also updated every included library to the latest available stable version, including faad 2.0, faac 1.24

Great, thank you. I guess you still use libfaac.dll like HeadAC3he does now, too? Is there a chance to transcode directly from 5.1 AC-3 to 5.1 AAC/MP4 with WinLAME in the future? Do you support MP4 file writing and tagging, too (the normal libfaac.dll cannot do this yet)?

[DeXT]

Originally posted by hans-jürgen
Great, thank you. I guess you still use libfaac.dll like HeadAC3he does now, too? Is there a chance to transcode directly from 5.1 AC-3 to 5.1 AAC/MP4 with WinLAME in the future? Do you support MP4 file writing and tagging, too (the normal libfaac.dll cannot do this yet)?

Yes I use the standard libfaac.dll which is also available at RareWares so you can safely replace it with a new release or a faster ICL compile. This is why I like dynamic link libraries (speaking of this, I tried to get rid of the custom nlame.dll and use the standard lame_enc.dll but I had to give up after I realized that its interface sucks and this would lead to reduced functionality, as it allows less control of the encoding from the host app).

About AC3 input support, I will probably add it sooner or later, but I first have to study which library to use, either liba52, azid or whatever else. Note, however, that a dedicated app like HeadAC3he will probabbly do a better job as it can downmix, normalize, amplify and the like, which is not really winLAME's field as a simple transcoding utility.

MP4 support is planned but not implemented yet (look at the to-do list). Tagging support will be added, too.

DeXT

[hans-jürgen]

Originally posted by DeXT
Yes I use the standard libfaac.dll which is also available at RareWares so you can safely replace it with a new release or a faster ICL compile. This is why I like dynamic link libraries

The problem I have with the normal libfaac.dll in CDex is that it crashes ("internal error in msvcrt.dll") when I want to encode a WAV file with it, although I can change the settings before clicking on "Start". The changed libfaac.dll from DarkAvenger works fine though, at least with HeadAC3he. Furthermore the default settings of libfaac.dll in CDex are completely wrong like using the Main profile etc., so I don't know if this would also be the case with your implementation. Anyhow, I'll test WinLAME today and report any problems either here or at Audiocoding.com.

About AC3 input support, I will probably add it sooner or later, but I first have to study which library to use, either liba52, azid or whatever else. Note, however, that a dedicated app like HeadAC3he will probabbly do a better job as it can downmix, normalize, amplify and the like, which is not really winLAME's field as a simple transcoding utility.

I don't know either which library is doing a better job of AC-3 decoding, foo_ac3.dll uses liba52 and only has one option to enable or disable DRC while AC3Filter has many more options using the same library. HeadAC3he needs azid.dll and also ssrc.dll for resampling which is a handy tool when combined with FAAC, because downsampling to 24 kHz gains a lot of coding efficiency for low bitrates.

MP4 support is planned but not implemented yet (look at the to-do list). Tagging support will be added, too.

That's great, you could also have a look at the new out_aac.dll (Winamp) and cool_faac.flt (CoolEdit/Adobe Audition) in the CVS for some ideas, because Antonio implemented these things just recently and mentioned that he designed his plugins in a way that other developers could easily use them for different applications.

[hans-jürgen]

Originally posted by hans-jürgen
Anyhow, I'll test WinLAME today and report any problems either here or at Audiocoding.com.

Works like a charm, no problems at all... very good work, DeXT. Now why does your libfaac.dll work on my Win95 sytem while the one from John33 or Case crashes in CDex?

[hans-jürgen]

Originally posted by hans-jürgen
Now why does your libfaac.dll work on my Win95 sytem while the one from John33 or Case crashes in CDex?

By the way, using their compiles of libfaac.dll in winLAME also ends in an internal Windows error (but in winlame.exe this time, not in msvcrt.dll) like in CDex. So I guess this must be a compiler issue... which one do you use?

And a small problem occurs when trying to encode to files that already exist in the target directory while not enabling the "overwrite files" option at the same time, because then winLAME simply shows "encoding complete" with the progress bars at 100% immediately, which is correct somehow, but might also confuse some people...

Last but not least: where did you hide the APE decoder? Or does winLAME simply seek the HDD for an existing DLL if it supposed to decode APE files?

[bond]

ugh, dext kills bond with wma support

being serious, nice tool of course!!

[DeXT]

Originally posted by hans-jürgen
By the way, using their compiles of libfaac.dll in winLAME also ends in an internal Windows error (but in winlame.exe this time, not in msvcrt.dll) like in CDex. So I guess this must be a compiler issue... which one do you use?

It's a plain MSVC compile with no special tweaking. I think I left the default project options that came with faac.

The weird part is, I tried it with John33's compile on RareWares and works like a charm here. However, the one that comes with HeadAC3he causes an access violation here, dunno why.

And a small problem occurs when trying to encode to files that already exist in the target directory while not enabling the "overwrite files" option at the same time, because then winLAME simply shows "encoding complete" with the progress bars at 100% immediately, which is correct somehow, but might also confuse some people...

This is the default winLAME behaviour, I didn't change anything from this part of the code. Perhaps you would like it to show a message box asking to overwrite the existing file? I can try to add this, too.

Last but not least: where did you hide the APE decoder? Or does winLAME simply seek the HDD for an existing DLL if it supposed to decode APE files?

It's not hidden at all, APE support has been there since the "pre1" release (I didn't code it) althought it was undocumented. It just loads any existing MACDll.dll from the system path; in fact it should work this way with any other dll, when not found on the program's directory. You only need to have Monkey's Audio installed on your system to enable APE input support (this is why it does not come with APE dll). Perhaps I should have added a note about this...

Originally posted by bond
ugh, dext kills bond with wma support

being serious, nice tool of course!!

Heh. In fact I first added WMA input support only because I wanted winLAME to be able to read these as a good transcoding tool, but then I found that I could also use the encoding feature for free as it comes in the same dll (basswma.dll).

Thanks for your kind words

DeXT

[alexnoe]

HA is regulary down for me

Don't use free.fr as ISP

[hans-jürgen]

Originally posted by DeXT
The weird part is, I tried it with John33's compile on RareWares and works like a charm here. However, the one that comes with HeadAC3he causes an access violation here, dunno why.

Sorry, apparently I got lost in my five different libfaac.dll's on my HDD, because I'm testing three different audio transcoders at the same time. I mistook DarkAvenger's first and slightly buggy version (26.05.04) for the latest one from Case (02.05.04) which works fine in winLAME, too, just like the one from John33 (20.03.04). But that one is still based on FAAC v1.23.5, so people should rather use yours (27.04.04) or Case's version for winLAME.

The reason why DarkAvenger's versions do not work with winLAME is probably caused by his changes due to 32bit input support for HeadAC3he. He explained them in the german Doom9 forum a few days ago.

All these different DLLs still crash in CDex 1.51, by the way, so maybe it initializes libfaac.dll the wrong way, I don't know.

Anyhow, while playing with the winLAME options for FAAC I found that the average bitrate and bandwidth settings offer nonsense values besides the correct defaults. First issue with ABR mode is that v1.24 no longer uses "bitrate per channel", but "total bitrate", i.e. depending on mono, stereo or multichannel input. So the lowest and highest values should be extended, e.g. from 10 kbps (for mono) to the one that is possible with the current FAAC ABR mode, probably 78.5 kbps x number of channels = ~448 kbps/6ch (not tested).

"Bandwidth" is not related to sample rate, but frequency cutoff, so the lowest value should be e.g. 3 kHz, and the highest 22 kHz. Do the wrong values like 44.1 kHz come from libfaac.dll itself, or is this caused by winLAME? I'm asking, because the source code might need some fixes then. I'm not sure if the LFE switch is still implemented in the source code either...

By the way, where did you get those estimated bitrate values for the quality slider from, are they based on some own tests? I would think that e.g. ~52 kbps/channel for -q 50 is much too high. It's also important to know that since v1.24 the cutoff changes automatically with -q and directly influences the overall bitrate this way.

Perhaps you would like it to show a message box asking to overwrite the existing file? I can try to add this, too.

That would be better in my opinion.

You only need to have Monkey's Audio installed on your system to enable APE input support (this is why it does not come with APE dll). Perhaps I should have added a note about this...

That's interesting, I have a macdll.dll in \windows\system, very likely from the installation of GX::Transcoder, another application which can also transcode video files.

Heh. In fact I first added WMA input support only because I wanted winLAME to be able to read these as a good transcoding tool, but then I found that I could also use the encoding feature for free as it comes in the same dll (basswma.dll).

But this is not WMA9, or is it? Talking about other input formats for winLAME: DTS would be nice, too.

[DeXT]

Originally posted by hans-jürgen
Sorry, apparently I got lost in my five different libfaac.dll's on my HDD, because I'm testing three different audio transcoders at the same time. I mistook DarkAvenger's first and slightly buggy version (26.05.04) for the latest one from Case (02.05.04) which works fine in winLAME, too, just like the one from John33 (20.03.04). But that one is still based on FAAC v1.23.5, so people should rather use yours (27.04.04) or Case's version for winLAME.

Okay, that has more sense then.

The reason why DarkAvenger's versions do not work with winLAME is probably caused by his changes due to 32bit input support for HeadAC3he. He explained them in the german Doom9 forum a few days ago.

Unfortunately I can no longer access the german Doom9 forum, it asks for a user name and a password. I'm interested in taking a look at his changes, too.

All these different DLLs still crash in CDex 1.51, by the way, so maybe it initializes libfaac.dll the wrong way, I don't know.

That's right, it misses some initializations needed on recent (1.23+) faac releases (shortctl, inputFormat & quantqual). I found this problem too when updating winLAME to be compatible with the current faac. An older faac dll should work with CDex, provided you can find it...

Anyhow, while playing with the winLAME options for FAAC I found that the average bitrate and bandwidth settings offer nonsense values besides the correct defaults. First issue with ABR mode is that v1.24 no longer uses "bitrate per channel", but "total bitrate", i.e. depending on mono, stereo or multichannel input. So the lowest and highest values should be extended, e.g. from 10 kbps (for mono) to the one that is possible with the current FAAC ABR mode, probably 78.5 kbps x number of channels = ~448 kbps/6ch (not tested).

This is a change on the faac command line frontend only, as libfaac still takes a bitrate per channel setting. However, it should be noted that the way winLAME is coded, I can't get the number of channels on the input files from the encoder settings page (be aware that in practice you can put mixed stereo & multichannel files on the input list). And I'm not sure of the convenience of allowing a total bitrate value here, as you the user must then be aware of the number of channels on the input file(s) in order to put a right value here. However, if you think it doesn't really matter I can change it.

Also note that ABR setting is not recommended since 1.23.5, instead the Quality value (VBR) should be used.

"Bandwidth" is not related to sample rate, but frequency cutoff, so the lowest value should be e.g. 3 kHz, and the highest 22 kHz. Do the wrong values like 44.1 kHz come from libfaac.dll itself, or is this caused by winLAME? I'm asking, because the source code might need some fixes then. I'm not sure if the LFE switch is still implemented in the source code either...

That's right, it should be called cutoff (or lowpass) setting. I simply didn't change it, as this module was originally coded by vividos. About the high allowed values, in fact the max allowed bandwidth is samplerate/2 so in theory with a 96 KHz source you can use a 48 KHz cutoff. And yes the LFE channel handling is already implemented on faac, from what I can read on the sources.

By the way, where did you get those estimated bitrate values for the quality slider from, are they based on some own tests? I would think that e.g. ~52 kbps/channel for -q 50 is much too high. It's also important to know that since v1.24 the cutoff changes automatically with -q and directly influences the overall bitrate this way.

It's only an orientative value and should not be really trusted. I uses a simple calculation which should be more or less accurate for values around q=100, but because of the nature of VBR encoding (as it's fixed quality, the resulting bitrate not only depends on frequency cutoff but also on the content itself) there's extremely hard to get a good figure here.

As an example, with some pop-style samples I get an average of 47 Kbps for q=50 and 91 Kbps for q=250, so the calculated values of 52-92 Kbps are fairly accurate here. However, with classical-style music I get lower values (42 & 72 Kbps respectively).

That would be better in my opinion.

Okay. Another item on my to-do list

That's interesting, I have a macdll.dll in \windows\system, very likely from the installation of GX::Transcoder, another application which can also transcode video files.

As I said the Monkey's Audio GUI also install it on the system path.

But this is not WMA9, or is it? Talking about other input formats for winLAME: DTS would be nice, too.

It's WMA9 according to BASS documentation at least. Note that you can encode in Lossless (by setting Quality=100%) which is a WMA9-only feature. However, due to the limited settings allowed in BASSWMA I can only use the fixed quality VBR mode, and not enter an average VBR value or use the VBR 2-pass mode as an example. I hope this is improved on future BASS releases.

About DTS, we'll see...

DeXT

[Asmodeus]

Very good tool
My sugestions (as always), only three words: VORBIS CHANNELL ORDER (for 6ch)
And AC3 input of course

[DeXT]

Originally posted by Asmodeus
My sugestions (as always), only three words: VORBIS CHANNELL ORDER (for 6ch)

Uh? It already uses Vorbis channel order when encoding to ogg, and this can be verified using CoreVorbis for playback (note that neither OggDS nor WinAMP will do it the right way, as they lack channel remapping).

In fact I'm the one behind the channel remap code on the TCMP Vorbis/AAC plugins, and by extension on CoreVorbis and CoreAAC. The same code is used here on winLAME.

DeXT

[hans-jürgen]

Originally posted by DeXT
Unfortunately I can no longer access the german Doom9 forum, it asks for a user name and a password. I'm interested in taking a look at his changes, too.

He didn't publish them there or elsewhere yet, but according to his answers and also the included readme files in HeadAC3he he'll probably send them to you if you mail him.

That's right, CDex misses some initializations needed on recent (1.23+) faac releases (shortctl, inputFormat & quantqual). I found this problem too when updating winLAME to be compatible with the current faac. An older faac dll should work with CDex, provided you can find it...

OK, thank you very much for this information. Anyhow, using the FAAC command line version with any CD ripper makes more sense (and works fine, too) at the moment, because it can directly write MP4/M4A files and tag them correctly with the iTunes tags.

And I'm not sure of the convenience of allowing a total bitrate value here, as you the user must then be aware of the number of channels on the input file(s) in order to put a right value here. However, if you think it doesn't really matter I can change it.

I was thinking of keeping the behaviour of faac.exe and libfaac.dll as similar as possible in order not to confuse users (and minimize the support effort for them... ).

Also note that ABR setting is not recommended since 1.23.5, instead the Quality value (VBR) should be used.

Yes, I know... But others may not, so it's good to mention it again here: It should only be used when defining exact files sizes (for DVD ripping/burning) or an almost constant bitrate for streaming purposes is more important than sound quality.

About the high allowed values, in fact the max allowed bandwidth is samplerate/2 so in theory with a 96 KHz source you can use a 48 KHz cutoff.[/B]

Hmm, theoretically yes, but practically nonsense... Anyhow, if you change the name to "Cutoff", it should be clear what the setting means.

And yes the LFE channel handling is already implemented on faac, from what I can read on the sources.

I meant that the on/off switch for LFE might have been disabled months ago to "always on", at least in the CLI frontend, but I'll have a look at the faac-checkin mailing list again.

It's only an orientative value and should not be really trusted. I uses a simple calculation which should be more or less accurate for values around q=100, but because of the nature of VBR encoding (as it's fixed quality, the resulting bitrate not only depends on frequency cutoff but also on the content itself) there's extremely hard to get a good figure here.

OK, I've tested it again, and this effect (and misunderstanding) is caused by the 16 kHz cutoff that winLAME uses for all -q settings (default behaviour before FAAC v1.24). If you adapt the cutoff to lower (or higher) values for lower -q settings (faac.exe does this automatically now), you'll get average bitrates according to the table on the Wiki page for FAAC.

It's WMA9 according to BASS documentation at least. Note that you can encode in Lossless (by setting Quality=100%) which is a WMA9-only feature. However, due to the limited settings allowed in BASSWMA I can only use the fixed quality VBR mode, and not enter an average VBR value or use the VBR 2-pass mode as an example. I hope this is improved on future BASS releases.

Wow, amazing, this is the first audio transcoder that doesn't need the whole ~4 MB Microsoft enchilada for WMA9 encoding then, and it even works on Win95, d'oh! And yes, 2-pass VBR encoding would be nice, also for FAAC, so if you are bored or interested in developing this, I'll soon get on your nerves with this issue as I've done it in the past with other developers...

[Asmodeus]

Originally posted by DeXT
Uh? It already uses Vorbis channel order when encoding to ogg, and this can be verified using CoreVorbis for playback (note that neither OggDS nor WinAMP will do it the right way, as they lack channel remapping).

In fact I'm the one behind the channel remap code on the TCMP Vorbis/AAC plugins, and by extension on CoreVorbis and CoreAAC. The same code is used here on winLAME.

DeXT

Ok
My fault. I was on wrong matrixmixer remap. So many test, so many confusions...
But of course I can look forward for AC3 input :?: I also sugest liba52.
Many thanx and sorry again for my clumsynes

[DeXT]

Originally posted by hans-jürgen
Hmm, theoretically yes, but practically nonsense... Anyhow, if you change the name to "Cutoff", it should be clear what the setting means.

Done.

I meant that the on/off switch for LFE might have been disabled months ago to "always on", at least in the CLI frontend, but I'll have a look at the faac-checkin mailing list again.

You are right, the frontend switches it on with >=6ch input files. However I found that it makes no difference on stereo files so I changed it to on by default.

OK, I've tested it again, and this effect (and misunderstanding) is caused by the 16 kHz cutoff that winLAME uses for all -q settings (default behaviour before FAAC v1.24). If you adapt the cutoff to lower (or higher) values for lower -q settings (faac.exe does this automatically now), you'll get average bitrates according to the table on the Wiki page for FAAC.

Sorry, this was actually a bug! The "auto" switch worked the opposite way, i.e. it was on when unchecked! This has been fixed in the new release below.

So, here you have a new (hotfix) release with the changes proposed by hans-jurgen. Here's the changelog:

What's new in winLAME-test beta2 (040609 release):

* AAC Output Module:
- Fix: auto bandwidth worked the opposite (on when unchecked)
- Enter total average bitrate (previously used a per-channel basis)
- Enter bitrate in Kbps instead of bps
- LFE channel on by default
- Changed "Bandwith" to "Cutoff" for clarification
* WMA Output Module
- Enter bitrate in Kbps instead of bps
* Miscellaneous:
- Added overwrite file warning

Download it here: winlame-test_b2.zip

(Sources available at the Hydrogenaudio post above)

DeXT

[hans-jürgen]

Originally posted by DeXT
You are right, the frontend switches it on with >=6ch input files. However I found that it makes no difference on stereo files so I changed it to on by default.

Right, the LFE has a dedicated single_channel_element (SCE) in AAC at the last position in the internal channel mapping, so it doesn't influence a stereo channel pair. Furthermore this option doesn't make much sense, because you can always switch off a present LFE in your audio mixer or elsewhere nowadays if you don't want it (additional bitrate for LFE is quite small, too).

By the way, do you plan to implement some sort of downmixing before encoding, too? That option makes more sense, because you can drastically lower the overall bitrate then, especially with 5.1 or more input channels. But it would be useful for stereo input that you only want to keep in mono in the AAC file, too. Downmixing could be realized with a separate module or simply by activating the internal options in the input decoder, e.g. in FAAD2 (don't know for AC-3 though).

And resampling to lower sample rates will increase the coding efficiency of FAAC, too, so including ssrc.dll like HeadAC3he could enable this method. Most useful sample rate is 24 kHz when transcoding from 48 kHz AC-3 files, by the way, which HeadAC3he does not offer yet.

Sorry, this was actually a bug! The "auto" switch worked the opposite way, i.e. it was on when unchecked! This has been fixed in the new release below.

I see... "automatic cutoff" before v1.24 meant adapting the cutoff to lower input sample rates, e.g. if it was downsampled to 24 kHz, the cutoff would be set to 12 kHz internally overruling the manual cutoff setting (Nyquist theorem).

* WMA Output Module
- Enter bitrate in Kbps instead of bps

By the way, the developer of GX::Transcoder mentioned that the basswma.dll only links to an installed WMA encoder from Microsoft on your HDD (found this info on the Unseen website), so it depends what version you have if it's really WMA9 or older. I once installed the WMA8 encoder (WMA9 normally doesn't install on Win95) and still have a wmvcore.dll from 2001 that seems to be linked in basswma.dll, so my successful encoding might also be a WMA8 one only. And WMP doesn't tell me which codec version was used when I play the file with it.

Download it here: winlame-test_b2.zip

I will test it today and report any problems here.

[hans-jürgen]

Originally posted by DeXT
* AAC Output Module:
- Fix: auto bandwidth worked the opposite (on when unchecked)

Works correct now, but the estimated bitrate values shown for the -q setting should be updated, too.

- Enter total average bitrate (previously used a per-channel basis)

Deviations from the expected bitrate in ABR mode are caused by the outdated table in the FAAC source code with bitrate vs. cutoff. The pop-up explanation when touching the shown bitrate value with the cursor should also be changed to "total bitrate" instead of "per channel" now. And the FAAC help screen in winLAME.chm needs to be udpated in some aspects, too (great help file nevertheless, by the way).

* Miscellaneous:
- Added overwrite file warning

That warning does not open up on Win95 immediately, the closed window is placed in the task bar instead (common problem with this OS version and newer Windows code).

It would be nice if winLAME could remember the last used codec like it does with the last input file after a new start already. That way I wouldn't have to change from LAME to FAAC each time.

When the encoding has finished, winLAME "forgets" the input file, i.e. I cannot go back just one step, change some settings and encode again, because I have to go back to the beginning and choose the input file again.