Technically speaking, would it be feasable to use an existing GPL'd SBR technique (PlusV for an example, just an example though) and interleave it into the existing AAC bitstreams to make a "poor man"'s AAC+?

What do you guys think, does that make any sense?

Just Remember SBR ™ is Registered by Coding Technologies. I dont know the Differences between the Enhancement Tool used by PlusV and CT SBR. As I know the difference is Coding technologies are using the Original mp3 codec from Frauhoffer Institute and PlusV works with Lame open Codec.

PlusV Developers say " its possible to develop a PlusAAC, please contact us" But remeber AAC means Advanced Audio Coding and is a Registered Trademark of DOLBY LABORATORIES (SOny and Frauhoffer Partnership) In this case the PlusV Developers need a Permission to Use their Codec.

Lame + SBR = plusV
Mp3 + SBR = mp3PRO ™

AAC + SBR = AACplus ™
Not Aint AAC + SBR = ???

No!
PlusV is this technologie in general, like SBR:
FhG-mp3 + SBR™ = mp3PRO™
Lame-mp3 + SBR™ = mp3PRO™ (if there are ever SBR™ specs they maybe implement it into Lame, but it will also be mp3PRO compatible)
Lame-mp3 + PlusV = M3V
FhG-mp3 + PlusV = M3V (also I don´t think they´ll ever implemnt PlusV)
So it doesn´t matter which mp3 encoder you use, if they use SBR™, output will be mp3PRO™, and if you use PlusV, output will be M3V.
PlusV hasn´t been implemented into any aac-codec (yet), so there is also no name for it.
But, also:
FhG-aac + SBR™ = AACplus™
PsyTEL-aac + SBR™ = AACplus™
FAAC-aac + SBR™ = AACplus™

I appologize for using ambigous or incorrect terms, but I'm more worried about the concept than the symantics...

Would it be possible to design a bandwidth-splitting, high-band coding system like PlusV or SBR that would fit in the AAC bitstream and imitate AAC+ when it comes out?

And since an operation like the PlusV analysis is performed on the wav file before encoding, PlusV doesn't have to license the encoder...

PlusV <original> => <cropped wav> + <PlusV data>
Encode <cropped wav> => <cropped AAC> (this step is independent of the PlusV technology, so PlusV creators wouldn't have to have licensing)
Mux <cropped AAC> + <PlusV data> => <AACplusV> (hopefully comparable to AAC+, but much less expensive?)

Does that make more sense? =P

I tried that, it really encodes the PlusV data first. the plusv.exe outputs two files, a new 22050Hz wav and a plusv-data file which is quite small (about 150KB for 3 minutes audio). Then I encoded the mp3 (with FhG, it offers better quality at low bitrates), but how to mux the mp3 file and the plusv-data now?
It seems that decoding works the same, first mp3 data is decoded and then the PlusV signal is modulated on that. If it works like that it would be easy to use AAC for that, too.

Edit: I found the source of the interleave.exe and was able to compile it. Mp3+PlusV sounds quite similar to mp3pro, both are not very good, just that PlusV sounds a lot better compared to mp3pro in a normal mp3 decoder.

Encoding works like that:

Works decoding like that:

I yust couldn´t find the plusv-decoder, otherwise you could test any format for plusv-quality, you just couldn´t mux both files toghether.

Edit 2: Very important! You _have_ to remove the vbr-tag in front of the mp3, otherwise the plusv-data will be out of sync and it sounds even worse.

I get the PlusV data out of sync even for plain .wav files - never mind introducing lossy coding to the non-PlusV part!

I've posted a message over at www.plusv.org but it's rather quiet over there - did anyone here suffer this problem?

Cheers,
David.

I yust found out how two decode the files, unfortunately -h doesn´t work with the plusv.exe and there is no readme, only the online faq.
It is really terrible out of sync, much more than with mp3, this picture speaks for itself:

This could also be an decoder problem, because the higher frequenzes are calculated from the lower correctly, they are just out of sync, but it doesn´t make sense if decoder has calculated the higher part from a wrong place in the wav, it seems more, that he doesn´t insert the high frequenzes at the right place, this could simply be a small buffer problem or something like that.
That the decoder says "Cannot read auxilliary data" at the end seems to be normal, because the wav is written correctly anyway.

Edit: I yust found out that you can mp3gain Mp3+PlusV files yust fine, also it doesn´t work correctly with mp3pro.

That's exactly my idea, just interleave the PlusV data into the AAC bitstream... For some reason, the PlusV encoder and decoder work just fine on my system... AMD AthlonXP 1800+, 256 MB, SBLive! Value...

So really, to make a GPL'd AACplus clone, one would simply have to interleave the PlusV data into the AAC bitstream and create an appropriate decoder... Hmm... >=D

*schemes*

I understand it wouldn't be decoder-compatible with AACplus, but it could be a closer-to-open-source alternative... Anyway. =P

Actually, an open-source fully-compliant AAC+ codec is feasible. Specifications and reference sources are available. It's not like MP3pro, that has no specifications available, therefore, it's impossible to create open-source implementations.

They work fine for me, too, just the out of sync-problem.


For free to download or only for developers of big companies? Could you post a link? I talked with the FhG guy on the Cebit who was demonstaring mp3/mp3pro/aac/aacplus to me and he said there is no specs out yet, neither for mp3pro, nor for AACplus. But he also said that there will be probably a public test encoder for aac(plus) like for mp3 (that only encodes 30 sec.) for download on a new website.

I talked about feasibility! There's no such codec ready yet, or even being planned, AFAIK.



When was it?
Since march AAC+ has been standardized, and therefore the specs are frozen. Now, it's possible to implement AAC+ tools from the specs (although CT did a good job making the specs cryptic enough to make any attempt to create working tools out of it a nightmare).

Actually, there have been AAC+ spec drafts since last year. I myself used one of these drafts coding huffman tables for the now closed FAAD2 SBR implementation.



That's very interesting! I look forward to that.

I yust read in this paper: http://www.ebu.ch/trev_291-dietz.pdf that SBR works identical like PlusV, the data is first run through a SBR-Encoder, the cropped wav is then encoded to aac and then the SBR-data and the aac is muxed. Wouldn´t it be better to couple both? So that the SBR part can better adjusted to the aac part.
I mean, where can you download the specs?

It was on the Cebit 2003 on 15.03.2003 and the FhG-guy said there aren´t any docs/specs about AAC+ yet. Where are these AAC+ specs? Why has the SBR implemenatation for FAAD2 stopped? Is menno now completly working for ahead and there won´t be any further developement of FAAD2 (at least no open, only in the closed nero sources)?

I don't get what you mean.

By "couple" you mean running them simultaneously?



ISO.

You'll have to pay first, of course.



http://mpeg.telecomitalialab.com/meetings.htm





Menno started it, but Ahead demanded exclusivity on the SBR decoder. That means FAAD2 can still support SBR in the future, but someone else will have to code it.



AFAIK, everything that is fixed/added to the Nero decoder goes to the Sourceforge CVS, except SBR.

Besides, even if Menno stopped updating FAAD2, someone else could take over the project. There's no problem with that.

Regards;

Roberto.

Sorry, I tried fixing this huge mess, but the forum software is too shitty.

That's what happened when I hit "edit":
http://pessoal.onda.com.br/rjamorim/shit.png

Edit: Something similar happened when I hit "quote"

Yes, it would be more efficent if the SBR and the AAC encoder would be one step, it could analize a block of x (x = length of SBR-frame / aac-frame) samples and maybe see that there are no high frequenzes in that block -> more bits left for other audio, but also see that for computing the higher frequnzes there are some information from the lower frequnzes needed which would normaly not encoded, I mean, SBR could be better if it would know from what it is calcualting the higher frequnzes and also directly influenze that. Also for bitrate managment this would be better, because it could calculate how much space to spend on each part.
So no free example code like dist10
You already started you said, will you be able to finish it?
Maybe the forum software doesn´t work with anything else than IE (so it is shitty).

Hrm... it's an interesting theory.

But I don't know how an SBR encoder works, so I can't enlighten you about this issue.

PlusV works like that because the SBR encoder works separatedly from the MP3 encoder. But things might be different on encoders where everything is together, like MP3pro and AAC+.



Ah! We were talking about specifications here (documents), not sources.

I don't know about the reference sources availability. Better ask someone with access to the MPEG CVS, like Ivan.

I guess they can be made available for download (if they already aren't).



No, I did a very simple part actually. I don't have enough knowledge to do everything.



No, that was a problem with the PHP software (the backend). It would happen on any browser.

D'Oh! http://www.audiocoding.com/wiki/index.php?page=SBR and
http://www.audiocoding.com/wiki/index.php?page=PlusV



Indeed...



The one and only place for the latest specifications of MPEG standards is the ISO that sells them on a CD at the cost of approximately two Ogg Vorbis T-shirts. But the MPEG site and the MPEG Audio Subgroup site also provide them as a free download on their FTP server normally when the specs are not brand new, e.g. MPEG-4 Version 2 specs and reference software. This is sometimes also true for the ISO that offers the uncompiled software and compatibility bitstreams for many MPEG standards for free on their server, see e.g. the link on the main MPEG homepage.

I don't know when the specs for MPEG-4 Version 3 (including High-Efficiency AAC) will be publicly available from the ISO, but probably they will wait with that until all national standardization bodies have confirmed this standard extension and AAC+ will be an International Standard (IS) then (in May 2003 according to an old time schedule).