IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
VisualOn AAC Encoder
Nic
post Apr 19 2011, 23:20
Post #1





Group: Developer
Posts: 65
Joined: 23-September 01
Member No.: 11



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 Audio
Coding (AAC) audio codec. The library is based on a codec implementation
by VisualOn as part of the Stagefright framework from the Google
Android project.


Anyway, couldn't get my current MSYS/MinGW environment to compile it from https://github.com/mstorsjo/vo-aacenc so I just whacked it all in Visual Studio 6.

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....

Cheers,
-Nic

This post has been edited by Garf: Jul 12 2012, 16:39
Go to the top of the page
+Quote Post
Garf
post Apr 20 2011, 08:23
Post #2


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



Looks suspiciously like the 3GPP reference code from Coding Technologies, but with the copyright notice of another company plastered on it.

Edit: I'm not the only one who thinks this:

http://spectralhole.blogspot.com/2010/12/a...encoder-or.html

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?

This post has been edited by Garf: Apr 20 2011, 08:31
Go to the top of the page
+Quote Post
Nic
post Apr 20 2011, 08:41
Post #3





Group: Developer
Posts: 65
Joined: 23-September 01
Member No.: 11



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.

I have no idea about how VisualOn came by the code, if they have a license or have just ripped it off. Debian/ffmpeg probably should get that confirmed....

Cheers,
-Nic



This post has been edited by Nic: Apr 20 2011, 08:44
Go to the top of the page
+Quote Post
menno
post Apr 28 2011, 16:03
Post #4


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



The 3GPP website is pretty clear about this: http://www.3gpp.org/FAQ#outil_sommaire_21
If they were granted some kind of special authorization it should be in this file: http://www.3gpp.org/ftp/Inbox/2008_web_fil...sues-update.doc
Go to the top of the page
+Quote Post
Garf
post Apr 28 2011, 19:32
Post #5


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



Reported to Google as Android issue 16431.

It's possible the right to re-license the Dolby code under the Apache license was bought by VisualOn...but that sounds rather strange. Especially as the copyright doesn't mention Dolby at all.
Go to the top of the page
+Quote Post
Ivan Dimkovic
post Apr 28 2011, 23:31
Post #6


Nero MPEG4 developer


Group: Developer
Posts: 1466
Joined: 22-September 01
Member No.: 8



QUOTE (Nic @ Apr 20 2011, 07:41) *
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 wink.gif

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.

This post has been edited by Ivan Dimkovic: Apr 28 2011, 23:36
Go to the top of the page
+Quote Post
stereotype
post Apr 29 2011, 04:22
Post #7





Group: Members
Posts: 40
Joined: 6-November 06
Member No.: 37260



Isn't this just like LAME? Source code only, free speech, etc...
Go to the top of the page
+Quote Post
Garf
post Apr 29 2011, 09:26
Post #8


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



QUOTE (stereotype @ Apr 29 2011, 05:22) *
Isn't this just like LAME? Source code only, free speech, etc...


LAME issue is related to patents. This has nothing to do with patents, it is about copyright.
Go to the top of the page
+Quote Post
Garf
post Apr 29 2011, 09:29
Post #9


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



QUOTE (Ivan Dimkovic @ Apr 29 2011, 00:31) *
QUOTE (Nic @ Apr 20 2011, 07:41) *
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.
Go to the top of the page
+Quote Post
Garf
post May 23 2011, 22:02
Post #10


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



FWIW, Google has closed this issue, essentially deferring it entirely to VisualOn ("who is re-confirming that they have the necessary rights").

So basically, using this is at your own risk.
Go to the top of the page
+Quote Post
aconverse
post Jun 9 2011, 20:19
Post #11





Group: Members
Posts: 19
Joined: 13-July 08
Member No.: 55753



QUOTE (Garf @ Apr 29 2011, 03:26) *
QUOTE (stereotype @ Apr 29 2011, 05:22) *
Isn't this just like LAME? Source code only, free speech, etc...


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.
Go to the top of the page
+Quote Post
Garf
post Jul 5 2011, 11:24
Post #12


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



QUOTE (aconverse @ Jun 9 2011, 21:19) *
QUOTE (Garf @ Apr 29 2011, 03:26) *
QUOTE (stereotype @ Apr 29 2011, 05:22) *
Isn't this just like LAME? Source code only, free speech, etc...


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 smile.gif
Go to the top of the page
+Quote Post
benski
post Jul 5 2011, 15:44
Post #13


Winamp Developer


Group: Developer
Posts: 669
Joined: 17-July 05
From: Ashburn, VA
Member No.: 23375



QUOTE (Garf @ Jul 5 2011, 06:24) *
QUOTE (aconverse @ Jun 9 2011, 21:19) *
QUOTE (Garf @ Apr 29 2011, 03:26) *
QUOTE (stereotype @ Apr 29 2011, 05:22) *
Isn't this just like LAME? Source code only, free speech, etc...


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 smile.gif


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.
Go to the top of the page
+Quote Post
LigH
post Oct 14 2011, 09:30
Post #14





Group: Members
Posts: 147
Joined: 20-November 01
Member No.: 503



Is vo-aacenc at all able to create HE-AAC or quality-based VBR?

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.

If VisualOn developed any HE-AAC codec, as reported on their software codecs page, it is possibly not this one.

QUOTE
Audio:
  • AAC, AAC+, eAAC+, AAC-BSAC, MP3, MP2, MIDI, AMR, AMR-WB, AMR-WB+


This post has been edited by LigH: Oct 14 2011, 09:35


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
lvqcl
post Dec 12 2011, 15:42
Post #15





Group: Developer
Posts: 3214
Joined: 2-December 07
Member No.: 49183



Amazing encoder. Sounds like sh#t even at 320 kbps.

...is it for androids only?
Go to the top of the page
+Quote Post
LigH
post Dec 12 2011, 15:47
Post #16





Group: Members
Posts: 147
Joined: 20-November 01
Member No.: 503



It was originally made for Android, but Nic was able to publish a Win32 version too.


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
nu774
post Dec 12 2011, 16:27
Post #17





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



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.
Go to the top of the page
+Quote Post
LigH
post Dec 12 2011, 16:43
Post #18





Group: Members
Posts: 147
Joined: 20-November 01
Member No.: 503



As long as it is not comparable to FAAC, not to mention even Nero or QuickTime, it won't interest many people...


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
smok3
post Jan 22 2012, 01:03
Post #19


A/V Moderator


Group: Moderator
Posts: 1709
Joined: 30-April 02
From: Slovenia
Member No.: 1922



just some observations:

git: https://github.com/mstorsjo/vo-aacenc
pdf: https://github.com/mstorsjo/vo-aacenc/blob/...CEncoderSDK.pdf

seems to be LC only, CBR only, limited to max 2 channels (from pdf). I did compile an ffmpeg that is using it (for OSX), but no abxing so far.

(It is interesting, since such ffmpeg bin should be freely redistributable)

This post has been edited by smok3: Jan 22 2012, 01:19


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
IgorC
post Jan 22 2012, 02:58
Post #20





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



Some results of one particular person.

http://d.hatena.ne.jp/kamedo2/
http://d.hatena.ne.jp/kamedo2/20120114
http://d.hatena.ne.jp/kamedo2/20120102
http://d.hatena.ne.jp/kamedo2/20110430/1304181738

The quality of VisualOn AAC encoder is pretty low.

This post has been edited by IgorC: Jan 22 2012, 02:59
Go to the top of the page
+Quote Post
smok3
post Jan 22 2012, 08:22
Post #21


A/V Moderator


Group: Moderator
Posts: 1709
Joined: 30-April 02
From: Slovenia
Member No.: 1922



Nice, so it does not really make sense to use VisualOn to replace the internal ffmpeg AAC encoder.


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
lvqcl
post Jan 22 2012, 09:48
Post #22





Group: Developer
Posts: 3214
Joined: 2-December 07
Member No.: 49183



QUOTE (smok3 @ Jan 22 2012, 04:03) *
I did compile an ffmpeg that is using it (for OSX), but no abxing so far.

Try dogies or rawhide ( http://www.ff123.net/samples.html ) or apocalypse. Easy to abx even at 320 kbps.

QUOTE (smok3 @ Jan 22 2012, 11:22) *
Nice, so it does not really make sense to use VisualOn to replace the internal ffmpeg AAC encoder.

The internal AAC encoder (-acodec aac -strict experimental) seems to be even worse (according to the results at http://d.hatena.ne.jp/kamedo2/20110430/1304181738)
Go to the top of the page
+Quote Post
nu774
post Jan 22 2012, 14:15
Post #23





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



What I tried was this song (and next song in this same album triggered the bogus bitstream bug). Quite easy to ABX at 320k.
Attached File  samp.zip ( 1.46MB ) Number of downloads: 130

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.
Go to the top of the page
+Quote Post
/mnt
post Jan 22 2012, 19:00
Post #24





Group: Members
Posts: 696
Joined: 22-April 06
Member No.: 29877



QUOTE (nu774 @ Jan 22 2012, 14:15) *
What I tried was this song (and next song in this same album triggered the bogus bitstream bug). Quite easy to ABX at 320k.


Oh great, yet another crappy AAC encoder! It seems to be just as bad as ffmpeg's internal one.

IMO Google's AAC support on Android is pretty poor.

CODE
foo_abx 1.3.4 report
foobar2000 v1.1.10
2012/01/22 17:32:38

File A: C:\Downloads\samp\samp\01 Nin-Com-Pop.flac
File B: C:\Downloads\samp\samp\01 Nin-Com-Pop.m4a

17:32:38 : Test started.
17:32:48 : 01/01 50.0%
17:32:51 : 02/02 25.0%
17:32:56 : 03/03 12.5%
17:33:01 : 04/04 6.3%
17:33:04 : 05/05 3.1%
17:33:09 : 06/06 1.6%
17:33:14 : 07/07 0.8%
17:33:18 : 08/08 0.4%
17:33:25 : 09/09 0.2%
17:33:30 : 10/10 0.1%
17:33:37 : 11/11 0.0%
17:33:42 : 12/12 0.0%
17:33:43 : Test finished.

----------
Total: 12/12 (0.0%)


Flanging and obvious disortion on the vocals.


--------------------
"I never thought I'd see this much candy in one mission!"
Go to the top of the page
+Quote Post
smok3
post Jan 23 2012, 00:02
Post #25


A/V Moderator


Group: Moderator
Posts: 1709
Joined: 30-April 02
From: Slovenia
Member No.: 1922



Thanks, finally found some time to patch my scripts - so now apple AAC is used and the sound is just piped back when ffmpeg does the video...

true vbr example
CODE
afconvert -v -f "m4af" -d aac -s 3 input.aif


or maybe
CODE
afconvert -v -f m4af -d aac -s 3 -u vbrq 46 input.aif


would that be the same as qtaacenc -tvbr 46 --highest --samplerate keep ?

This post has been edited by smok3: Jan 23 2012, 20:21


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st April 2014 - 06:53