VisualOn AAC Encoder

2011-04-19 23:20:40

Hi,

Apologies if I have missed it, but has the VisualOn AAC Encoder been checked out by you guys? It's recently been added in as an optional encoder for ffmpeg, but not sure how it compares to the great AAC encoders (one imagines it fares better than ffmpeg's current internal encoder)

The README of the library says:

Quote

VisualOn AAC encoder library

This library contains an encoder implementation of the Advanced AudioCoding (AAC) audio codec. The library is based on a codec implementationby VisualOn as part of the Stagefright framework from the GoogleAndroid project.

If you're in the mood grab it from (Edit: patent violation removed) and give it a test. Its little test app is simple and old school so writes out to ADTS AAC files rather than MP4. Usage Example: vo-aacenc.exe -r 128000 RhymePays.wav RhymePays.aac

I doubt it's great - but would be interested to know how far some good ears consider it behind the mighty Neros and Apples of this world....

This is not a bad encoder, but it's worse than Nero and Apple. And it's hardly new. Did VisualOn buy a free license for the code or what? I would be a bit cautions with including this everywhere, as the legality of the code looks dubious to me. But it already seems to be in debian or ffmpeg...do they know about the origin of this code?

VisualOn AAC Encoder

Very interesting Garf - I was not aware of that, it does looks very suspect! How disappointing....especially as it's related to "do no evil" google.

Hmm... even if it turns out that the code is not licensed properly, it might happen that Google was not aware of this (e.g. if the vetting process, if there is one, is done in a way that might not involve Google proactively doing the IP check)

I'm not saying scenario is impossible - just that there might be few possibilities, apart from the "do no evil" Google being somehow implicated in this

But, in any case, if it turns out that the code is not licensed properly - it will not be a good PR for Android for sure.

VisualOn AAC Encoder

Very interesting Garf - I was not aware of that, it does looks very suspect! How disappointing....especially as it's related to "do no evil" google.

Hmm... even if it turns out that the code is not licensed properly, it might happen that Google was not aware of this (e.g. if the vetting process, if there is one, is done in a way that might not involve Google proactively doing the IP check)

It's quite possible Google has a contract with VisualOn that makes VisualOn liable if there are copyright issues with the code. Actually, that is almost certain.

But such a contract will not help other people who use the code on good faith.

LAME issue is related to patents. This has nothing to do with patents, it is about copyright.

Until version 3.81 LAME included ISO dist10 source code (hence "Lame Aint an MP3 Encoder") so there is a similarity.

FWIW faac and faad1 also use ISO reference code.

There is no similarity wrt. patents. LAME doesn't ship executables because those actually infringe the patents, unlike source code that doesn't do anything. Google is shipping this code in executable form on Android. But again, this is not about patents, so this is completely and utterly irrelevant.

This also isn't about ISO reference code. It's about 3GPP reference code. They're most certainly not the same. Notably, the 3GPP reference code doesn't suck

LAME issue is related to patents. This has nothing to do with patents, it is about copyright.

Until version 3.81 LAME included ISO dist10 source code (hence "Lame Aint an MP3 Encoder") so there is a similarity.

FWIW faac and faad1 also use ISO reference code.

There is no similarity wrt. patents. LAME doesn't ship executables because those actually infringe the patents, unlike source code that doesn't do anything. Google is shipping this code in executable form on Android. But again, this is not about patents, so this is completely and utterly irrelevant.

This also isn't about ISO reference code. It's about 3GPP reference code. They're most certainly not the same. Notably, the 3GPP reference code doesn't suck

I am not a lawyer, but I don't believe there is anything wrong in using the 3GPP or ISO code in binary form in a standards-compliant product (weird license text aside). The issue that Google has here is that they've potentially republished 3GPP source code under their own copyright notice and license text.

VisualOn AAC Encoder

Nic's encoder demo seems to default to 64 kbps without bitrate parameter; and even with, it seems to create LC-AAC only – which sounds obviously flawed at such a bitrate. Furthermore, even though MediaInfo reports it as VBR, I doubt that its bitrate changes noticably, which may be related to limitations in either Nic's demo application or the encoder itself, who knows; I am no C++ coder, I can't read sources easily.

VisualOn AAC Encoder

I tried this before.One song was quite easily ABX-able at 320k bps. Another song stopped playing in the middle, since AAC bitstream was invalid. So, I've reported bug to mstorsjo.It's fixed in mstorsjo's repos, but I don't know about the google's code base.

VisualOn AAC Encoder

What I tried was this song (and next song in this same album triggered the bogus bitstream bug). Quite easy to ABX at 320k.[attachment=6843:samp.zip]Looking inside of resulting bitstream, you will find it's mostly padded with continuous NUL(0x00) bytes. You will effectively get half the size down or so just by compressing the resulting AAC with gzip or something.Therefore, audible quality at 320k is not surprising at all.