Thanks for posting that link, Igor! I've also been waiting for the publication of the report, namely Figures 3 and 6.To answer your question: (e)SBR - just like any other coding tool in USAC, I think - can be turned off. In fact, we did so when testing the new stereo tool intended for "bitrates where SBR is typically not used" (the report of that experiment is available here).And one more note: the name USAC will probably change.Chris
I recon, apart from some niche applications, USAC will remain obscured, just like AAC for the average user.
sooner or later all kinds of multimedia material will be detached from the physical media. Once that is the case, it only makes sense to use the best encoders available.
Well, (HE-)AAC is used in DAB+, DRM, DMB, Youtube, iTunes Store, H.264 video from mobile devices, and some more. Whether these are niche applications is debatable, I'd say.
Think of it this way: years or R&D and over a million Euros/Dollars went into the standardization of AAC and now USAC. I wouldn't understand why one should give away the use of such highly specialized, sophisticated technology for free.
Quotesooner or later all kinds of multimedia material will be detached from the physical media. Once that is the case, it only makes sense to use the best encoders available.Both absolutely true. But the media creators (music distributors, digital camera manufacturers, etc.) already nowadays license the AAC encoders, so it seems they are willing to pay for the technology. Of course it's a different thing if you create your own media content, e.g. edit home videos or your band's music. Isn't there any commercial software like Adobe Premiere for Linux with in-the-box state-of-the art encoders?
I'd be curious to see USAC and Opus put to the test when the bitstreams freeze, and the encoders become available.
The only thing that bugs one, is that not all codecs are freely available. Sometimes, it is even dangerous to use them, in case of license violations.
I like your precise choice of words here ...
your Linux distributor of choice licenses a HE-AAC (or USAC) decoder library (i.e. pays for it), and bundles it with Linux so that every software can access that decoder to play encoded files. Would that solve the problem?
Don't worry, I'm sure nobody participating in this thread has any intention of starting a flame-war. I'm just trying to understand your point. So, let's assume your Linux distributor of choice licenses a HE-AAC (or USAC) decoder library (i.e. pays for it), and bundles it with Linux so that every software can access that decoder to play encoded files. Would that solve the problem?
- to pay for a library it would not be in real OS spirit (although i imagine that certain mainstream distros would do it)
the clash is mostly due to the fact that there is real world outside, so basically linux users would want to use their other hardware (ipods?) to play the same files...., otherwise webm would most likely be already adopted (i think google still bundels chrome with h.264 decoder...).
Nice, It will be great to see an implementation of it any time soon. A good implementation helps a lot for fast adoption of standard. As example, x264 plays important role in H.264 standard.
USAC verification test report
If we are able to achieve perceptual transparency in bitrates under 50kbps within the next five years, that would be pretty amazing.
On top of that you can use those new general purpose data compression tools, that can compress input regardless of content by ~30 % - and because their effect is given independent from the contents you can recursively feed their output back into them and compress every piece of audio down to 1 bit. - Amazeing!