Log in

View Full Version : Project announcement : New opensource AAC DirectShow filter, hosted on corecodec.org


Pages : 1 2 [3] 4

Wilbert
15th July 2003, 15:23
A bunch of warnings:

1) Besweet (still ?) produces invalid 5.1 wav's if bitrate > 2Gb. Use HeadAC3he for this.

2) This problems holds for every AAC encoder (not just Nero's one).

3) The channels in 5.1 wav and 5.1 aiff are also ordered differently:

5.1 wav: FL, FR, C, LFE, RL, RR
5.1 aiff: FL, RL, C, FR, RR, LFE
5.1 aac: C, FL, FR, RL, RR, LFE

see: http://www.avisynth.org/index.php?page=GetChannel

DeXT
15th July 2003, 15:26
Originally posted by ChristianHJW
IIRC then DeXT has made a fixed WAV input plugin for nero 5.5 or 6, not sure here. He posted about it on hydrogenaudio.org AFAIK, search their board for posts from DeXT or De_xt, and you'll find it for sure .... My fixed WAV plugin for Nero only solves the issue with large (> 2GB) WAV files, which are very common when more that 2 channels are being used. However it does not fix the channel remap issue. You can find it here (http://www.hydrogenaudio.org/index.php?showtopic=9944&st=25&#entry112418).

To manually remap the channels you may edit the *.mux file to match the required channel configuration as posted by Ivan on this thread (http://www.hydrogenaudio.org/index.php?showtopic=10986). However, note that you'll need an updated faad/CoreAAC/WinAMP/TCMP plugin compiled against the latest libfaad2 CVS release to be able to hear the channels on the right locations. And AFAIK binaries for these have not been made publically available yet (they should in few days).

tiki4
15th July 2003, 16:01
So that means that:

1) Channel reordering in a BeSweet .mux file may work,

but:

2) it's totally senseless to do so right now, until the new binaries are released (well, I don't feel like compiling right now)

Thanks for all the info,

tiki4

rjamorim
15th July 2003, 16:17
Originally posted by robUx4
Yet another GPL clone ? The QPL is a bit like that. I suggest using that. And if you want compatibility with GPL, just dual-license it :)

From what I know, they don't trust enough the GPL in keeping closed software from adopting it.

That's very bad, because this clone would most probably be automatically incompatible with the GPL. Then, all GPLd projects using FAAD2 (CoreAAC, DReaM, Mplayer...) would have to stop doing so.

For that reason, I urge whoever read this to mail Ahead (http://www.ahead.de/en/content/c1015424317180.html) explaining that the GPL is enough for what they need (heh, it's been surely more time and tested against loopholes than any "homebrewn" license) and the adoption of another license would make the sources incompatible with most software that has been written for them.

Mr. Richard Lesser (Ahead CEO) seems to be a nice, reasonable guy, so hopefully he'll listen before much damage is done. :)

bond
15th July 2003, 17:32
sent a mail

hopefully ahead will change their mind, so that aac-he will have a future...

DeXT
15th July 2003, 19:28
@Wilbert: you asked for some AAC standards. I found the following through Google:

http://www.tnt.uni-hannover.de/project/mpeg/audio/#mpeg4

Here you can find both MPEG-4 Audio V1 and V2 standards.

http://www.chiariglione.org/mpeg/working_documents.htm#MPEG-4

Here on the MPEG-4 Audio section, you'll find the ISO/IEC 14496-3:2001/FPDAM 1 ("Bandwidth extension") standard, also known as SBR.

I found pretty funny that the SBR specs are freely available on the web above. If I were an OSS Codec developer I'd want to take a look at it ASAP ;)

hans-jürgen
15th July 2003, 20:09
Originally posted by Wilbert
2) This problems holds for every AAC encoder (not just Nero's one). Not when the encoder (like FAAC) can read any input file (also transcoded multichannel AC-3) from its stdin, because then you don't need a temporary WAV file at all. This is e.g. possible when using foobar2000 as a GUI for that, see the Wiki page for more:

http://www.audiocoding.com/wiki/index.php?page=FAAC

3) The channels in 5.1 wav and 5.1 aiff are also ordered differently:

5.1 wav: FL, FR, C, LFE, RL, RR
5.1 aiff: FL, RL, C, FR, RR, LFE
5.1 aac: C, FL, FR, RL, RR, LFE FAAC v1.18 from July 13, 2003 can also remap different input multichannel layouts with its new -I switch that defines the position of the Centre and the LFE channel. The default configuration assumes a WAV file (i.e. "-I 3,4"), AC-3 would need "-I 2,6" and AIFF "-I 3,6", although the strange positioning of front and back stereo pairs might still cause M/S matrixing problems (correlating the wrong channels then maybe, would need some testing).

The FAAC source code is available as a package of a weekly CVS snapshot at http://www.audiocoding.com/download.php.

@DeXT: A foo_mp4.dll compiled on July 9, 2003 is available from Case's web site, so at least foobar2000 should handle this new multichannel layout in FAAD2 correctly:

http://www.saunalahti.fi/~cse/html/foobar0.7.html

I'm not sure if the downmixing is implemented already, but foobar can do the downmix independently with its own DSP modules, as far as I know.

And the sites you found with the ISO specifications are official ones from the MPEG, so nothing to be excited about. ;) But they only offer older standards as free downloads, the newest ones are only available from the ISO for a fee on a CD (~$50.00). So what you found are the Final Drafts (FD) from 2001, not the current specs from 2003. That's also the reason why a developer would have a hard time when using them and hoping the result would be compatible with e.g. Nero's HE AAC implementation.

ChristianHJW
15th July 2003, 20:36
Originally posted by rjamorim Then, all GPLd projects using FAAD2 (CoreAAC, DReaM, Mplayer...) would have to stop doing so.

There is no problem here meanwhile. Toff has rewritten all parts taken from the old GPL borgtech filter, so he can easily license CoreAAC with the same license as FAAD3 ....

DeXT
15th July 2003, 21:44
Originally posted by hans-jürgen
@DeXT: A foo_mp4.dll compiled on July 9, 2003 is available from Case's web site, so at least foobar2000 should handle this new multichannel layout in FAAD2 correctly:

http://www.saunalahti.fi/~cse/html/foobar0.7.html

Yes I can verify that the latest foo_mp4 plugin has support for the new channel mapping. I created a custom WAV using a modified *.mux file with the channel order required for AAC and fed Nero with it. The resulting mp4 sounds nicely using foo_mp4.

And the sites you found with the ISO specifications are official ones from the MPEG, so nothing to be excited about. ;) But they only offer older standards as free downloads, the newest ones are only available from the ISO for a fee on a CD (~$50.00). So what you found are the Final Drafts (FD) from 2001, not the current specs from 2003. That's also the reason why a developer would have a hard time when using them and hoping the result would be compatible with e.g. Nero's HE AAC implementation.
I already know that these are from the official site, and that they are not up to date. Wilbert was asking for freely available standards through the net, and I pointed him to it. However, my comment was due to the fact that despite all the secretism involved in the SBR code these days, the specs (well at least a working document) can be found freely on the net.

bond
15th July 2003, 23:32
Originally posted by ChristianHJW
Toff has rewritten all parts taken from the old GPL borgtech filter, so he can easily license CoreAAC with the same license as FAAD3 ....great to hear that :p

rjamorim
16th July 2003, 00:53
Originally posted by ChristianHJW
There is no problem here meanwhile. Toff has rewritten all parts taken from the old GPL borgtech filter, so he can easily license CoreAAC with the same license as FAAD3 ....

So no point in crediting BorgTech at RareWares anymore?

ChristianHJW
16th July 2003, 04:08
... please wait until this version will be in CVS and your compile is made from it Roberto ....

bond
18th July 2003, 11:16
any chance to get the latest coreaac version even without sbr, as it seems that sbr will still take some time
(menno on holiday, open license issues and nero6 release date was postponed to 25th july)...

rjamorim
24th July 2003, 05:48
Originally posted by bond
sent a mail

hopefully ahead will change their mind, so that aac-he will have a future...

It seems the bitching payed off. It's early to guarantee, but I have been told by an Ahead insider that FAAD2 and the SBR code will be released under the GPL. And it should happen next friday.

Animaniac
24th July 2003, 07:51
Originally posted by rjamorim
It seems the bitching payed off. It's early to guarantee, but I have been told by an Ahead insider that FAAD2 and the SBR code will be released under the GPL. And it should happen next friday.

Friday the 25th or the 1st.

Nic
24th July 2003, 10:15
Thanks for all the campaigning on our behalf Roberto :) And for keeping us informed :)

-Nic

rjamorim
24th July 2003, 12:45
Originally posted by Animaniac
Friday the 25th or the 1st.

It should be the same day Ahead officially releases Nero6. So, unless they postpone it once again, the 25th ;)

Thanks for all the campaigning on our behalf Roberto :) And for keeping us informed :)

No problem, dude.

Regards;

Roberto.

ChristianHJW
24th July 2003, 16:23
Thats really good news .. thanks for the info Roberto .... i am really looking forward to be able to test Nero 6, now if only all matroska team members would get licensed copies as a present from Ahead, just because we are so nice guys, that would be cool :D ...

rjamorim
25th July 2003, 02:01
Originally posted by ChristianHJW
now if only all matroska team members would get licensed copies as a present from Ahead, just because we are so nice guys, that would be cool :D ...

Hehe. I didn't get a free copy myself. Menno says I'm too unsafe because I'm warez addict and I might spread it.

Fucker. :B

ChristianHJW
25th July 2003, 10:14
Originally posted by rjamorim
Hehe. I didn't get a free copy myself. Menno says I'm too unsafe because I'm warez addict and I might spread it.
Fucker. :B

LOL !!! LMAO !! Not sure, but they would probably put us in the same corner of the spectrum, so i think we wont get it either :D .....

Nic
25th July 2003, 11:19
I remember the old days when I even had my name on the developers list of FAAC and was discussing improving its huffman bugs, and Ivan was barely releasing more than an improved ISO reference version of AACEnc? Do you reckon, I could get one with thoughts of nostalgia?....

...Nah, I didn't think so either.lol. ;)

-Nic

bond
29th July 2003, 11:50
now the sbr code is here (under gpl :) )!!!

go toff go :D


read menno's post on ha here (http://www.hydrogenaudio.org/index.php?showtopic=11753) (down atm)
johnv's announcement on doom9 is here (http://forum.doom9.org/showthread.php?s=&threadid=58473)

Wilbert
29th July 2003, 12:25
Roberto compiled a new FAAC (still without sbr code I guess, but with the channel remapping bug corrected): http://64.246.62.80/~hydrogenaudio.org/index.php?showtopic=11494
Guess he didn't update the version number on the RareWares site :)

bond
29th July 2003, 12:27
Originally posted by Wilbert
still without sbr code I guessthe sbr code will only be available for the decoder side!

[Toff]
29th July 2003, 13:47
The CoreAAC code is now in CVS :) and support SBR.
It's not tested a lot (for example channel remapping) and so probably not bug proof :D

a temporary experimental ;) build is available here

CoreAAC_1.0b4_20030729-1.exe (http://blacksun.corecodec.org/core/CoreAAC_1.0b4_20030729-1.exe)
CoreAAC_1.0b4_20030729-1.zip (http://blacksun.corecodec.org/core/CoreAAC_1.0b4_20030729-1.zip)

bond
29th July 2003, 14:07
great!

downmix to stereo works great
sbr decoding seems to work also

the bitrate isnt shown correctly -> 220kbps although sbr file at 65kbps...
the zip file isnt downloadable

sorry i cant say anything about channel remapping

[Toff]
29th July 2003, 14:13
Originally posted by bond

the bitrate isnt shown correctly -> 220kbps although sbr file at 65kbps...
the zip file isnt downloadable
sorry i cant say anything about channel remapping
Thanks,
Yes, bitrate display is wrong for sbr, i will fix that later, i still collect bug :) .
Thz zip link should be fixed now.

bond
29th July 2003, 14:49
just some small "optical" things:

1) perhaps it would look better if you the downmix option would show up under a "settings sub-headline" in the info tab like in corevorbis
i dont know if there is also postgain available for aac like for vorbis?
2) under about tab, after faad2 2.0 rc1 there seem to be too much spaces before the "-"
3) it seems that the info and the about tab dont have the same height, you can see that when you switch between the two

as i said nothing really important...

rjamorim
29th July 2003, 17:37
Winamp plugin and command line decoder, for anyone interested:

http://pessoal.onda.com.br/rjamorim/in_mp4.exe
http://pessoal.onda.com.br/rjamorim/faad.zip

hans-jürgen
29th July 2003, 18:15
Originally posted by Wilbert
Roberto compiled a new FAAC (still without sbr code I guess, but with the channel remapping bug corrected): http://64.246.62.80/~hydrogenaudio.org/index.php?showtopic=11494
Guess he didn't update the version number on the RareWares site :) The related bugfix happened on July 21, 2003 and the current FAAC version is still 1.18, because knik didn't update the number. This means that direct transcoding from AC-3 when combined with foobar2000 is possible now, and the -I switch is not needed, because foo_ac3.dll already reorders the channels to a 5.1 WAV layout which is the default mapping in FAAC 1.18. See also this thread:

http://forum.doom9.org/showthread.php?s=&threadid=55069&perpage=20&pagenumber=3

SBR won't be implemented in FAAC (the open source encoder) as long as no one takes a look at the ISO reference software and specifications for MPEG-4 HE AAC (when available) and tries it... ;)

bond
31st July 2003, 13:49
one more thing about the info tab:

i mentioned that when the downmix option is ticked it is always shown that the aac streams have 2 channels (even if they have 6 channels)
i think it would be better if always 6 channels are shown under the info tab when a 6 channel file is used (even if they get downmixed)...

Herske
1st August 2003, 00:54
Hello all,

I read this thread carefully but I still do not know how to extract the *correct* HE .aac out of mp4 container.

I have tried:
-mp4ui 0.95 - the extracted HE .aac file is recognised as LC in foobar2k and winamp

-mp4creator60 (v0.9.8.6 ) - the same problem.

I'm using the SBR decoders for both winamp and foobar, the .mp4 file plays perfectly; I've also tried forcing mpeg-4 conversion, in mp4creator and mp4ui: still no luck.

Thanks in advance for any help,
/herske.

rjamorim
1st August 2003, 03:50
MPEG4ip still doesn't recognize HE AAC. That's why it doesn't work well with this profile.

CruNcher
1st August 2003, 04:44
@Herske

Nero has buildin .aac creation you have to activate the checkbox that says Export to ISO AAC file and then also a .aac file is created.

Herske
1st August 2003, 08:20
Thanks for the replies.

Cruncher, I tried this, and the .aac file is still reported (in foobar 2k) as being LC instead of HE.

So, is it any way to mux HE files in mkv?

Thanks,
/herske.

tiki4
1st August 2003, 10:05
Hi there,

I got a serial for Nero 6 some days ago and have the same problem. It seems that even Nero exports a LC AAC file and just strips off the SBR part of the file (Menno?). However, there is a rather simple way to mux your files if you are a little bit experienced with Graphedit. Just install the 3ivx codec from 3ivx.com. This codec comes with a MP4 splitter filter (I think this was mentioned before). Now render your HE-AAC-MP4 files in Graphedit, remove the CoreAAC and DirectSound output filters and connect the pin of the MP4 splitter with Gabest's MatroskaMuxer and that one with the FileWriter. I tried this with the Ogg Muxer from Tobias and it plays perfectly. This is not the most newbie friendly solution at the moment, but I think Koepi and Nic will come up with a solution shortly.

Regards,

tiki4

[Toff]
1st August 2003, 10:39
Don't forget that HE AAC is still backward compatible.
A decoder that can't handle the SBR part will still decode the AAC LC part of the file. So make sure that the decoder you use support SBR or you file will be seen as a classic AAC LC file.

Also it's not possible to detect if a .aac file has SBR information or not in it without decoding it (there is no information in the headers about SBR). So if foobar display the file information before decoding it will probably show AAC LC.

About matroska, there is the same problem at the muxer level, currently mkvmerge makes no difference between AAC LC and HE AAC. It use the same ID. The current version of CoreAAC will not handle that correctly (dshow need to know the output sample rate before decoding). I have now a version that works using a little tricks but we are still discussing the use of a different ID.

Nic
1st August 2003, 11:22
@Toff: Could you please state some more info on this (the tricks your using, etc)? Else ill catch you on IRC and talk more about it ;) (when you say ID are you refering to the same kind of ID you get in ADTS headers?) (Thanks alot :) )

@Tiki: At worst, ill have to wait to see how mkvmerge does it, then do it the same way, but ill look into it tonight :)

-Nic

Herske
1st August 2003, 11:27
Toff: I was using the correct SBR decoders, it was the first thing I checked.


Great advice, tiki, it worked perfectly. The resulting .aac files plays ok with CoreAAC, which recognises it corectly as having SBR.

PS. Foobar 2k and winamp can't play the resulting file, error: "Max number of scalefactor bands exceeded" and mkvmerge doesn't recognise the resulting .aac file, but I have finally managed to mux everything correctly using Graphedit and MatroskaMuxer filter form Gabest.

tiki4
1st August 2003, 12:28
@[Toff]:

Now I'm a little bit confused:

Does that mean that Nero 6 exports AAC files with MPEG-2 ADTS headers (where high efficiency profile isn't defined) that still contain the SBR information but e.g. the new Winamp 2 plugin compiled by John33 doesn't see the SBR content of the file because, well, because of what? I tried to mux such a file that was exported by Nero but the resulting video wasn't decoded with SBR by CoreAAC. Really confusing :confused:

However, the Graphedit method is working, we'd just need a MP4 parser filter independent from 3ivx, so that CVS OggMux just has to build a filter graph. As I said, it works perfectly when demuxed with the MP4 splitter and muxed into OGM or Matroska via DirectShow.

Regards,

tiki4

tiki4
1st August 2003, 12:31
Just to mention that: One can hear if is decoded correctly or not quite easily. Try for yourself: encode in Nero 6 and export ISO-AAC thingie. Load the resulting AAC into Winamp, or extract from MP4 with patched mp4creator from RareWares (--mpeg-version=4 switch). Both resulting AAC files are played wrongly by the in_mp4 plugin.

tiki4

CruNcher
1st August 2003, 13:30
@tiki4


resulting video wasn't decoded with SBR by CoreAAC. Really confusing


nope not really the problem is all muxer like MP4UI, mp4creator and also mkvmerge have to be made compatible to support the HE AAC profile, with the workaround CoreAAC version every muxed aac file is sampled*2 @ decoding. It works fine in my encodes only problem is the 3ivx Mp4 splitter it doesn't connect to the newest ffdshow maybe its ffdshows fault though in VLC its working fine but sound is not sampled*2 but i allready contacted a VLC developer and he will look @ it this evening :). i think in at least 1 week we will see that interoperability @ muxing and playing for HE AAC is fully given in the major muxer/players :)

[Toff]
1st August 2003, 15:53
Originally posted by Nic
Could you please state some more info on this (the tricks your using, etc)? ... when you say ID are you refering to the same kind of ID you get in ADTS headers?

I was talking about the matroska ID used. (A_AAC/MPEG2/LC, A_AAC/MPEG4/SBR ...)
Currently mkvmerge, with or without SBR always use A_AAC/MPEG2/LC because it use .aac as input format and in .aac there is nothing in the header to know if the file contain SBR informations.
In fact it's not really a problem for the decoder. The decoder will find the information in the frame data. But for example in dshow, we need to know the output samplerate to create the mediatype before decoding.

In mp4 this information is present so there should be no problem.

The trick i was talking about is at the decoder level.
If i don't have enough information about the SBR presence and if the input samplerate is <= 24Khz i create a media type with samplerate * 2. Then when i decode, if i found that SBR is not present, i double the samplerate.

When the muxer will use the right ID (by adding a command line switch, or by decoding the first frame, or by some more advanced detection on frame data) the demuxer will be able to recreate a mediatype with more information so the resampling trick will not be needed anymore.

Originally posted by tiki4 Does that mean that Nero 6 exports AAC files with MPEG-2 ADTS headers (where high efficiency profile isn't defined) that still contain the SBR information ...

Yes that's what nero is creating.
And about winamp2 plugin it's maybe updated only for mp4 and not for AAC.

Originally posted by tiki4
However, the Graphedit method is working, we'd just need a MP4 parser filter independent from 3ivx, so that CVS OggMux just has to build a filter graph. As I said, it works perfectly when demuxed with the MP4 splitter and muxed into OGM or Matroska via DirectShow.

One comment about the graphedit method, just to let you know that the file created will then use the windows ACM compatibility mode. And so maybe not be supported on x-platform.

robUx4
1st August 2003, 16:01
We need AAC+ encoders be able to write in matroska directly. It will be easier... :D

tiki4
4th August 2003, 06:54
@robUx4: :D

@[Toff]:

Right now I'm not caring too much about *nix compatibility, but you're surely right. I'd really like to see MKV based on an OS-independent solution (well, is UCI making progress?). On the other hand, Nic is making steady progress with OggMux and OGMuxer including AAC support :cool:

Cheers, and thanks for clarification,

tiki4

mikeson
15th December 2003, 02:03
@CoreAAC devels:

May I ask what is the current status of supporting replaygain in CoreAAC? Is it supported now? My tests didn't prove that, so if it is not, will it be supported in future?

Thanks.

[Toff]
15th December 2003, 13:53
The problem is to get those replaygain values which are stored at container level.
The decoder only get the AAC frames, so the splitter need to give those information to the decoder. I don't know if any splitter do this at the moment (mp4, matroska, ogm, avi).

bond
17th December 2003, 19:19
so we need to get muxer developers (cyrius, mosu, shitowax and alexnoe ;) ) to pass this info, when muxing into their formats

Atamido
18th December 2003, 01:40
It would probably be better if someone made a generic ReplayGain DirectShow filter that connected between the codec and the AudioRenderer. Then that could have a simple interface to accept a replaygain value from the splitter and adjust the audio levels accordingly.

I don't imagine this would be that hard to do.

shitowax
18th December 2003, 09:41
I didn't find the time to code that yet, but this replay gain can be easily set from the splitter (before streaming, retrieve the volume interface of the graph and set it to the right level). And anyway, at least for .mp4 and .mov, it's contained in the file format, not in the audio bitstream, so, my opinion is that it's the business of the splitter to set that, not the audio decoder.

Originally posted by Pamel
It would probably be better if someone made a generic ReplayGain DirectShow filter that connected between the codec and the AudioRenderer. Then that could have a simple interface to accept a replaygain value from the splitter and adjust the audio levels accordingly.

I don't imagine this would be that hard to do.