I know it's being used by NPR and a few radio stations, but any consumer support? And is it just a better version of HE-AAC V2? Or will it require new software/hardware support to use all it's features.
Hm, interesting topic. I did some Googling and am currently reading up but here is this: http://www.iis.fraunhofer.de/en/ff/amm/pro...html#tabpanel-3 (http://www.iis.fraunhofer.de/en/ff/amm/prod/digirundfunk/digirundf/xheaac.html#tabpanel-3)
Availability
Codec implementations of xHE-AAC for use in DRM and streaming applications are available for the following hardware platforms:
PC (Windows/Mac OS X/Linux)
ARM (decoder only)
MIPS (decoder only)
Texas Instruments C6x, DaVinci, OMAP (decoder only)
Analog Devices Blackfin (decoder only)
Apple iOS® SDK (decoder only)
Android™
DRM broadcast encoder solutions based on Fraunhofer’s ContentServer technology, as well as third-party implementations, already support xHE-AAC. All DRM receiver chipsets belonging to the initial mass-market generation include xHE-AAC from market launch.
Patent licensing:
Via Licensing has issued a call for essential patents for the USAC Baseline Profile to enable a patent pool license for xHE-AAC which is expected to be available in 2015.
I suggest you look at this document when you have a chance. Lots of technical stuff about the encoder but they also clearly define use-cases, design goals etc.
http://www.iis.fraunhofer.de/content/dam/i...per_xHE-AAC.pdf (http://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_Technical-Paper_xHE-AAC.pdf)
Based on their own charts from the above document, it is the next step in HE-AAC and really excels at extremely low bitrates with diminishing returns as bitrate increases (as is the trend with most lossy codecs, with newer ones performing better at lower bitrates). I reproduce the chart below.
(http://i.imgur.com/AKAu07I.png)
By the time you reach 64kb/s it's about the same as previous version of HE-AAC. I think they were really aiming at 16kb/s.
Ok, I found some great real-world examples thank to another poster at HA.
Right click and save this 49 megabyte video to hear quite a few lot bitrate examples, including comparisons with existing radio codecs at the beginning and speech, music and mixed examples.
http://www.drm.org/wp-content/uploads/2013...v2_20130913.avi (http://www.drm.org/wp-content/uploads/2013/09/DRM-xHE-AAC-Demo_v2_20130913.avi)
Post with these links found here: http://www.hydrogenaud.io/forums/index.php...st&p=875162 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106938&view=findpost&p=875162)
There is great discussion and sharing of MUSHRA results further down, though not all is about xHE-AAC.
Regarding encoders, one poster said (in Sep. 2014), "Bad news is that while the standard was adopted in 2007 there is no publicly available encoder. That's 7 years ago.
Same goes for USAC/xHE-AAC (2011)."
Here is another post worth checking. http://www.hydrogenaud.io/forums/index.php...st&p=875351 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106938&view=findpost&p=875351)
So, in summary, based on that thread xHE-AAC isn't necessarily leaps and bounds ahead of other specialty codecs but I think it is interesting given that it is in the widely supported AAC family and if the encoder were made available to the public it could be great for streaming archives at universities and libraries or even portable versions of podcasts.
Hm, interesting topic. I did some Googling and am currently reading up but here is this: http://www.iis.fraunhofer.de/en/ff/amm/pro...html#tabpanel-3 (http://www.iis.fraunhofer.de/en/ff/amm/prod/digirundfunk/digirundf/xheaac.html#tabpanel-3)
Availability
Codec implementations of xHE-AAC for use in DRM and streaming applications are available for the following hardware platforms:
PC (Windows/Mac OS X/Linux)
ARM (decoder only)
MIPS (decoder only)
Texas Instruments C6x, DaVinci, OMAP (decoder only)
Analog Devices Blackfin (decoder only)
Apple iOS® SDK (decoder only)
Android™
DRM broadcast encoder solutions based on Fraunhofer’s ContentServer technology, as well as third-party implementations, already support xHE-AAC. All DRM receiver chipsets belonging to the initial mass-market generation include xHE-AAC from market launch.
Patent licensing:
Via Licensing has issued a call for essential patents for the USAC Baseline Profile to enable a patent pool license for xHE-AAC which is expected to be available in 2015.
Strange that they mention the hardware platforms, but not the actual codec implementation names. I assume that there are software xHE-AAC encoders available for Android and PC based on that list.
Is xHE-AAC a Fraunhofer only thing? How do you actually encode using xHE-AAC as of today?
Thought I would share an update. The post contains a video explanation and is from October 2015.
http://www.audioblog.iis.fraunhofer.com/xhe-aac-2/ (http://www.audioblog.iis.fraunhofer.com/xhe-aac-2/)
Moreover, at this year’s IBC Fraunhofer IIS presented with “StreamS Live” from Modulation Index, LLC the first professional streaming encoder supporting xHE-AAC.
More on this encoder here:
http://www.iis.fraunhofer.de/en/pr/2015/20...streamS_v3.html (http://www.iis.fraunhofer.de/en/pr/2015/20150910_xhe-aac_streamS_v3.html)
Sounds like encoders are limited to specialty hardware (or at least specialty-hardware-exclusive software right now).
Glad it's getting out there, though. Watching the AVI file from above again, I would love to be able to encode some 24kbps xHE-AAC files as the background music in the video was 24kbps! Could be damn near transparent for audiobooks, talk radio programs and well-produced podcasts. Would be fantastic for college lectures and similar as well.
Lastly, here is an app that allows you to stream some xHE-AAC from a radio station.
https://itunes.apple.com/us/app/xhe-streami...1032502998?mt=8 (https://itunes.apple.com/us/app/xhe-streaming/id1032502998?mt=8)
This demo is streaming Radio Haugaland in Norway at 16 kbit/s. Doesn't sound great but impressive for the bitrate. I'm really interested in hearing speech so I'll have to tune in and see if they have any talk shows.
Lastly, here is an app that allows you to stream some xHE-AAC from a radio station.
https://itunes.apple.com/us/app/xhe-streami...1032502998?mt=8 (https://itunes.apple.com/us/app/xhe-streaming/id1032502998?mt=8)
And for Android: https://play.google.com/store/apps/details?...ev.egil.xhedemo (https://play.google.com/store/apps/details?id=com.lexadev.egil.xhedemo)
o-l-a-v. Thank You for the link.
This demo is streaming Radio Haugaland in Norway at 16 kbit/s. Doesn't sound great but impressive for the bitrate. I'm really interested in hearing speech so I'll have to tune in and see if they have any talk shows.
As for me quality is wonderful for 16 kbps, both music and speech. Perfectly enjoyable, no big annoyance. I think speech actually has better quality. xHE-AAC uses enhanced AMR-WB+ for speech (and actually for music as well at 8-24 kbps) and as speech is near monish or panned so new parametric stereo tools make good job here.
Nice radio btw
o-l-a-v. Thank You for the link.
This demo is streaming Radio Haugaland in Norway at 16 kbit/s. Doesn't sound great but impressive for the bitrate. I'm really interested in hearing speech so I'll have to tune in and see if they have any talk shows.
As for me quality is wonderful for 16 kbps, both music and speech. Perfectly enjoyable, no big annoyance. I think speech actually has better quality. xHE-AAC uses enhanced AMR-WB+ for speech (and actually for music as well at 8-24 kbps) and as speech is near monish or panned so new parametric stereo tools make good job here.
Nice radio btw
I wrote that post when I'd only listened for a minute. I listened to it on my walk home with earbuds and was shocked to hear that the fat synth bass on a song was reproduced quite well. It's honestly perfectly acceptable and not too distracting after a minute or two. Here's hoping more stations adopt xHE-AAC and encoders and decoder support spread quickly.
As for me quality is wonderful for 16 kbps, both music and speech. Perfectly enjoyable, no big annoyance. I think speech actually has better quality. xHE-AAC uses enhanced AMR-WB+ for speech (and actually for music as well at 8-24 kbps) and as speech is near monish or panned so new parametric stereo tools make good job here.
Nice radio btw
Too good to be true...
The streaming WAS at 16 kbps: right now it's at 48 kbps.
If you don't trust my words just check the following resources (the xHE-AAC stream name is "rh.x16"):
http://stream.radioh.no:443/ (http://stream.radioh.no:443/)
And the same page as seen on 2015-05-10:
https://web.archive.org/web/20150510200224/....radioh.no:443/ (https://web.archive.org/web/20150510200224/http://stream.radioh.no:443/)
Just compare the "Bitrate:" info section of the stream between the two and you'll easily notice the difference.
This demo is streaming Radio Haugaland in Norway at 16 kbit/s.
Stupid question: how do you play USAC streams and files on Windows
without using iTunes ?
Any player I've tried just failed, e.g. foobar2000:
Unable to open item for playback (Unsupported file format):
"http://stream.radioh.no:443/rh.x16"
I've listened to the demo stream on my iPad, but every few minutes the sound gets completely garbled and I have to restart the app. Anyone else with the same problem?
I've listened to the demo stream on my iPad, but every few minutes the sound gets completely garbled and I have to restart the app. Anyone else with the same problem?
Yes, I also had this problem. Sometimes it lasts longer than others. I assume it is due to the fact that it is a test stream being used by a tiny number of people for sales purposes and the like.
As for me quality is wonderful for 16 kbps, both music and speech. Perfectly enjoyable, no big annoyance. I think speech actually has better quality. xHE-AAC uses enhanced AMR-WB+ for speech (and actually for music as well at 8-24 kbps) and as speech is near monish or panned so new parametric stereo tools make good job here.
Nice radio btw
Too good to be true...
The streaming WAS at 16 kbps: right now it's at 48 kbps.
If you don't trust my words just check the following resources (the xHE-AAC stream name is "rh.x16"):
http://stream.radioh.no:443/ (http://stream.radioh.no:443/)
And the same page as seen on 2015-05-10:
https://web.archive.org/web/20150510200224/....radioh.no:443/ (https://web.archive.org/web/20150510200224/http://stream.radioh.no:443/)
Just compare the "Bitrate:" info section of the stream between the two and you'll easily notice the difference
Well, this is disappointing. It would've been a true breakthrough if that stream was 16kbps. Too good to be true. Still, subjectively speaking, there were no truly bothersome artifacts, just the typical excessive sibilance.
If it really is 48Kbps then it actually sounds really bad(for that bitrate)
If it really is 48Kbps then it actually sounds really bad(for that bitrate)
It's annoying that I can't really check since VLC and similar won't play this xHE-AAC and there's only one damn stream.
Tried it with iTunes and it won't play audio and it clearly is misreading the stream:
(http://i.imgur.com/jyJHO81.png)
Ok, some more sources.
NPR Labs-related.
Summary article: http://www.radioworld.com/article/npr-labs-eyes-streaming-technology-/223059
Full report: http://nprlabs.org/sites/nprlabs/files/documents/codec/20130920%20Streaming%20Codec%20Study%20Report.pdf
This reinforces the point about xHE-AAC losing its advantage once it reaches to the mid-range of bitrates used by HE-AAC and the bottom of LC-AAC.
(http://www.radioworld.com/Portals/0/rw-streaming%20codec%20figure%203.jpg)
If it really is 48Kbps then it actually sounds really bad(for that bitrate)
The saga continues!
I wrote the web director for Radio Haugaland and got a response (at like 11pm over there - poor guy!)
Hello,
I apologize for not speaking Norwegian. I have a technical question. Your station has a stream that uses the xHE-AAC codec. I am very interested in it because you are the only station making an xHE-AAC stream available to the public.
I want to ask: what is the bitrate of your xHE-AAC stream? When I look at your status page (http://stream.radioh.no:443 ) the bitrate for /rh.x16 says "48000" but that seems too high.
Thank you,
Hi,
We are creating HLS for xHE (http://theradiohub.com/hls/)at our lab at the moment. You need the our apps to do playback.
16k is now available from our Icecastserver if you need it. Playback can be done using our xHE apps for Android (https://play.google.com/store/apps/details?id=com.lexadev.egil.xhedemo) and iOs (https://itunes.apple.com/no/app/xhe-streaming/id1032502998?l=nb&mt=8).
We create apps for radiostations on demand both for mp3, aac and xhe - and for both Android, Windows and iOs.
You might also want to check out our new app-platform (https://play.google.com/store/apps/details?id=com.lexadev.radiohaugaland) (Android demo).
Egil
A-Media AS
That seems like a pretty clear confirmation that it is in fact 16kbps. When you look at the page (http://stream.radioh.no:443) all the other numbers are two digits and are commonly used bitrates for streaming. The fact that it displays 48000 makes me think that due to it being an unusual format the Icecast server reads the sampling rate as the bitrate (as 48kHz is very common).
So, given that info, I revert back to my initial impression: Impressive! I'm listening some more and the artifacts are definitely there but as shown in the demo video from earlier in the thread, 16kbps in almost any other codec sounds like a particularly bad music implementation when you're put on hold on the telephone. Again, really wish I had an encoder and decoder so I could do some listening tests next to HE-AAC and Opus.
I copy and pasted the raw stream link yesterday into Google Chrome and it started downloading the stream. I then checked how much bandwidth my network interface is using and it showed around 48Kbit/s, but are we really sure that the test Apps use the same stream.
Just tested the app.
I'm eager to test this on my streams! The quality is a tad worse than 24 kbps HE-AAC
The bitrate is really around 20 kbps with network overhead. But works fine on GPRS with low signal.
(http://s17.postimg.org/u5i4n5ykr/Screenshot_2016_04_09_12_16_22_1.jpg) (http://s17.postimg.org/f9jlfkn65/Screenshot_2016_04_09_12_16_22_1.png)
(http://s23.postimg.org/wconzx6av/Capture.jpg) (http://s28.postimg.org/a6bmcv625/Capture.png)
Ok, some more sources.
NPR Labs-related.
Summary article: http://www.radioworld.com/article/npr-labs-eyes-streaming-technology-/223059
Full report: http://nprlabs.org/sites/nprlabs/files/documents/codec/20130920%20Streaming%20Codec%20Study%20Report.pdf
This reinforces the point about xHE-AAC losing its advantage once it reaches to the mid-range of bitrates used by HE-AAC and the bottom of LC-AAC.
(http://www.radioworld.com/Portals/0/rw-streaming%20codec%20figure%203.jpg)
I can't get that pdf, any altenative links? (That graph/page looks questionable to me: LAME at 128kbps not enough for a silly radio station? Lack of Opus/good old Vorbis?)
Try Archive.org (http://web.archive.org/web/20160328103640/http://nprlabs.org/sites/nprlabs/files/documents/codec/20130920%20Streaming%20Codec%20Study%20Report.pdf). Here is a mirror (https://dl.dropboxusercontent.com/u/61700377/misc/20130920_Streaming_Codec_Study_Report.pdf).
j7n: Thanks, right so this was rated without the requirement to actually abx the original (so the source could be rated 4/6 for example).
I can't access the NPR Labs website. Maybe it's because I'm in Europe.
Are there any xHE-AAC encoders available for ABX testing yet? The article on radioworld compared / tested against MP3 and various other AAC variants, but not against its "competitor" (Opus).
I'd like to do some tests myself, etc.
I can't access the NPR Labs website. Maybe it's because I'm in Europe.
Are there any xHE-AAC encoders available for ABX testing yet? The article on radioworld compared / tested against MP3 and various other AAC variants, but not against its "competitor" (Opus).
I'd like to do some tests myself, etc.
See j7n's post above you: https://dl.dropboxusercontent.com/u/61700377/misc/20130920_Streaming_Codec_Study_Report.pdf
I don't know about encoders. I think it is still quite proprietary and professional for now.
From the same paper https://dl.dropboxusercontent.com/u/61700377/misc/20130920_Streaming_Codec_Study_Report.pdf
Interestingly, results were quite flat starting at 32 kbps, suggesting that listeners did not hear marked
improvements at higher bit rates
:o
This is so wrong I don't even know which argument to start with.
Let's just put it in a technical terms.
If your codec and /or test present the same not so good quality (MUSHRA 60 = MOS 3) both at 24-32 kbps and higher bitrate 64 kbps then there is something
really wrong with your codec and/or test.
Also according to their test their xHE-AAC 64 kbps = MP3 96 kbps. Even MP3pro (MP3+SBR) 64 kbps is on par with legacy MP3 96 kbps. So this particular tested implementation of xHE-AAC doesn't bring nothing new to 14 years old SBR (?).
Another interesting statement about bitrates and 4G.
Based on our research, we recommend keeping the bit rate of streams
as low as possible, consistent with high audio quality. For the HE‐AAC codec, we believe this balance is achieved
at a constant stream rate of 48 kbps
Something obvious but still. Audio quality isn't high at 48 kbps with any codec. OK quality, maybe.
I don't beleive that such low bitrate 48 kbps can prevent dropout.
1. It's impossible to "pre-buffer" a real-time radio.
2. The rate of 4G is far superior than any logical audio bitrates. I have an unlimited 4G 30 Mbits connection on my phone. A speed can drop down to ~300-700 kbps in worst congestion case (and I still get Spotify working at 96/160/320 kbps)
Still far superior to 48-100 kbps. But if there is some area with no 4G You lose a connection per completely then even xHE-AAC 16 kbps won't help here.
So all this point of very low bitrate on 4G is very moot.
P.S. They push low bitrates and xHE-AAC for an obvious reason.
Why would someone pay more if LC-AAC (which is almost 20 years old) is doing already great at 80-96 kbps without all that extra pay for a newer low-bitrate codec with a load of patents for semi-parametric or parametric coding tools like SBR, PS, SBS, MPS, advanced LPC, IGF, ELT etc.
IgorC: A result like that is a little shaky, and I think their graphs are a little weird, too.
I think as for low bitrates in the mobile market it doesn't make much sense these days, as providers are pushing for higher bandwidths constantly.
A point where it makes sense to me though, is when it comes to streaming costs. Most providers (mine included) charge for traffic volume. So, when you have less traffic you pay less, so that makes sense. Especially, when you're using that streaming service in your car, etc. where sound quality isn't perfect anyway.
But I'm only really interested in how it performs against Opus. What they claim is one thing, as long as I can't test it myself, it's not really that interesting to me. I don't see myself using DRM over AM, as I don't really have a need for that. But I guess it'd make sense if you're in a remote area, or on a boat or something, and all you can get is AM radio.
I'm a big fan of Codec2, which to me covers the "lower end" of the bandwidth spectrum. I'm a little surprised by the fact the radio operators don't settle on Opus, as it is free, it is a low-latency codec, and provides adequate quality on low bandwidths. I'm not a marketing person, so I guess there's something I simply don't see.
polemon,
Most providers (mine included) charge for traffic volume. So, when you have less traffic you pay less, so that makes sense.
That's true.
But I'm only really interested in how it performs against Opus.
That depends on particular implmentation(encoder) of xHE-AAC.
While there is only one Opus reference implementation there can be multiple xHE-AAC encoders with different audio quality.
You can find some samples of USAC (xHE-AAC) here https://hydrogenaud.io/index.php/topic,106938.msg875351.html#msg875351
That is a reference high quality USAC encoder which isn't available.
I have compared it with Opus some years ago and here are my conslusions:
32 kbps, stereo. USAC is better than Opus. It's not a surprise as Opus is a low-delay codec and frequency leakeage is big at very low bitrate. While USAC benefits from 100+ ms delay.
48 kbps, stereo. That's where it starts changing. Opus 1.1 was somwehat inferior to HE-AAC and USAC. But the latest alpha 1.2 should be already on par with USAC and somewhat better than HE-AAC.
64 kbps and higher bitrates, stereo. That's where both Opus and USAC already push the limits what can be done with lossy audio compression. Both are good and better than HE-AAC and LC-AAC. It will take at least 5 years or so to make something better than that.
But that's with USAC reference highest quality encoder which isn't available publicly.
That particular xHE-AAC encoder from paper isn't very high qualtiy implementation of standard.
If You want to know an average MUSHRA scores for Opus the I can provide them knowing the previous results of Hydrogenaudio tests and from my personal experience with it.
MUSHRA:
Opus 48 kbps ~65-70.
Opus 64 kbps ~80-85
Opus 96 kbps ~90-95
The main rule is MOS (hydrogenaudio tests) = MUSHRA/20
Also there is some information about Opus vs EVS (enhanced for low delay xHE-AAC) at 48 kbps, mono
https://hydrogenaud.io/index.php/topic,106938.msg875399.html#msg875399
But Opus 1.2 (which is in development now) shoud do better
it's a shame that no encoders are available for general use. it seems this codec is very restricted, only in dedicated hw for now.
As I was looking into AMR codecs, I've stumbled over this page: http://www.voiceage.com/Patent-Portfolio.html
I don't know how authoritative it is, but I was told, that U-Boat patents are mostly a thing of the past. Given what is described there, patents for xHE-AAC will expire in 2031 - or to be more precise: the last one of those will expire in 2031.
According to this: https://www.iis.fraunhofer.de/en/ff/amm/impl.html there are SDKs available, that run on a plethora of systems, including PC (including Linux). How to get those SDKs, I have no idea.
VoiceAge "sells" xHE-AAC: http://www.voiceage.com/xHE-AAC.html however I'm not sure how they sell it. They claim to be a "codec provider", I wonder if that means, they do anything beyond licensing, really. As far as I understand it, the SDK or whatever software has to come from FhG IIS anyway.
I occasionally check out the usual places on the internet for a pirated copy of the SDK, but so far I couldn't find any. I guess since there aren't that many users, the probability of the SDK leaking outside of its designed realm is rather minimal. And tbh, I think this is the only way we'd get a chance at having a go at xHE-AAC for anytime soon.
Internet isn't a viable option for patented formats anymore.
Google tries to get rid of AAC in Youtube (still supported in MS and Apple browsers )and pushes Opus. Spotify uses Vorbis and they can't afford a patented format. WhatsApp uses Opus. Netflix uses patent free formats for mobile clients as well.
MPEG Surround is a standard since 2007 (10 years ago! ) and its presence is null in internet community.
The same goes for xHE-AAC. Something is telling me (and I don't know what is it O:) ) the same will go for a latest standard 3DA which improves xHE-AAC quality furthermore.
If there is possibility for a new codec in future that will be available for internet community that will be Ghost (or whatever it will be called). https://people.xiph.org/~xiphmont/demo/ghost/demo.html
Ghost can improve quality comparing to Opus more than considerably as it can use higher latencies (100-200ms) and some additional complexity. Today ARM chips can decode at least 2x-4x complexity of Opus without dropping smartphone's battery life.
PS. BTW xHE-AAC's sweet spot is 24-32 kbps stereo. It's slightly better than HE-AAC at >=48kbp bitrates.
Chances that xHE-AAC will be any better than Opus at >=48 kbps are zero.
PS2. There is also a new format AC4 from Dolby. Dolby has acquired Coding Technologies (creators of SBR and Parametric Stereo). AC4 is similar to xHE-AAC (if not better)
If there is possibility for a new codec in future that will be available for internet community that will be Ghost (or whatever it will be called). https://people.xiph.org/~xiphmont/demo/ghost/demo.html
Ghost can improve quality comparing to Opus more than considerably as it can use higher latencies (100-200ms) and some additional complexity. Today ARM chips can decode at least 2x-4x complexity of Opus without dropping smartphone's battery life.
OK, so when it uses higher latencies, it's meant just for unicast streaming, etc.? Opus was designed to be a low-latency codec for VoIP, etc. that just happened to be good all round.
So Ghost will not replace Opus, merely it will be the "true" replacement for Vorbis, I take it?
You're right.
Amazing stuff and ideas but... Ghost really? Should we create an association to pick names for open source projects? :)
Vorbis, Opus and Ghost aren't names that I would prefer either. :)
In my opinion some generic naming like Open Audio Codec 1 (OAC1) as for Vorbis , low delay OAC2 (LD-OAC2) as for Opus are easy to understand.
Even better, Xiph Audio I (XA1, XA2...).
The future royalty-free video codec is "AV1" (AOMedia Video 1). More clear impossible.
Vorbis, Opus and Ghost aren't names that I would prefer either.
Well, the names like that are usually chosen for the same reason Linux distributions have names like "Ubntu" or "Fedora". The idea is to have a nice martketable name, which also speaks to a community, etc.
However this might swing ther other way: the MPEG numbering, layering, parting and whatever becomes a complete mess, with overlapping naming schemes and naming collisions.
the ITU has a numbering scheme which works half-good, I'd say, but it's still somewhat confusing.
The On2 VPn numbering scheme for video codecs was fine, I think, though. Numbering schemes usually tend to overcomplicate things, so I'm kinda not in favor of that. I'd name it after the person or group mainly involved in its invention or development, similar to how naming works with things like RSA, LZW, Keccak, etc.
If there is possibility for a new codec in future that will be available for internet community that will be Ghost (or whatever it will be called). https://people.xiph.org/~xiphmont/demo/ghost/demo.html
Ghost can improve quality comparing to Opus more than considerably as it can use higher latencies (100-200ms) and some additional complexity. Today ARM chips can decode at least 2x-4x complexity of Opus without dropping smartphone's battery life.
I wait for that day so eagerly. They are dropping some serious promises/targets on the table. This format could be a real game changer if and when it will be a thing. I hope we won't have to wait so long for it.
It seems Ghost is back at being in limbo: https://wiki.xiph.org/Ghost
IgorC: did you do this on their talk page: https://wiki.xiph.org/Talk:Ghost ¦D
Monty's page says "Copyright 2011" and I doubt there has been any changes to it since.
xiph.org has a thing for silly sounding names, their project name on the forefront of that, etc. But also "Vorbis", "Daala", "Ogg".
g=943699 date=1502928032]
It seems Ghost is back at being in limbo: https://wiki.xiph.org/Ghost
Pretty much it is at this moment.
So I gave http://stream.radioh.no:443/ a try.
Listening / Getting the StreamdumpThanks to
mpv,
youtube-dl, and
ffmpeg, listening to the /rh.x16 stream is actually possible on Linux, and I'm pretty sure on Windows, too. However, it seems the toolchain is kinda struggling as it is.
Simply playing the stream directly with mpv, is quite low on errors:
$ mpv http://stream.radioh.no:443/rh.16
yields the following error right at the start:
[ffmpeg/audio] aac: channel element 2.15 is not allocated
Error decoding audio.
however right after that, the stream starts playing quite nicely.
Data SpecificsWith the help of youtube-dl, I managed to download a sample length of the stream.
Inspecting it with ffmpeg yields this:
[aac @ 0x59159c0] Estimating duration from bitrate, this may be inaccurate
Input #0, aac, from 'rh-rh.16.part':
Duration: 00:09:45.52, bitrate: 16 kb/s
Stream #0:0: Audio: aac (HE-AACv2), 32000 Hz, stereo, fltp, 16 kb/s
Note the "16 kb/s". The Duration is out by around 20 seconds, in that ~10min sample. The file is 1189420 (1.2M) bytes in length, and is a pure AAC dump.
I can play the file back using mpv, but ffmpeg complains about "Reserved SBR extensions is not implemented", which seems to be kindof a minor thing (?), as the file plays alright.
When playing this file with "--msg-level=all=v", playing the stream directly with the switch using mpv, or inspecting the file with ffmpeg, it never mentions "xHE-AAC". Instead, the AAC stream is identified as HE-AACv2.
Tool VersionsMy youtube-dl version is: "2018.01.21" (probably not the latest one).
I tried two versions of ffmpeg, "3.3.7" and "N-45774-g223f3dff8-static https://johnvansickle.com/ffmpeg/" compiled just a couple days ago.
mpv version is: "0.27.2".
I'm using Fedora 27.
Sound QualitySince no log output of any of the tools I've used reports anything about "xHE-AAC" or "USAC", I'm not sure whether the USAC component is simply ignored. FFmpeg reports "HE-AACv2" with 16 kb/s, and that's pretty much it. Since all tools here use ffmpeg as back-end, I guess this isn't a surprise.
Having said that, the stream sounds "OK", given the low bitrate. However any sounds resembling noise, like someone making an 's', 'f', 'sh', or 'z' sound etc., sound all alike, and incredibly harsh. Similar to a cassette tape recorded with DC bias. Another analogy is perhaps very small speakers, like the ones you'd find on a cheap cellphone or an old 80's pocket radio. I imagine playing that stream through the speakers of a cellphone or cheap bluetooth speakers would be adequate; I wouldn't want to listen to it in my car, though. FM radio sounds much cleaner than this.
If anyone cares, I can upload a sample, together with one or two samples of one of their higher-quality streams for comparison.
Given that I don't know whether my tools are decoding the stream correctly, I'm unsure whether the (subjectively) bad sound quality is down to xHE-AAC simply being used with such a low bitrate, or if it's down to my tools not being able to decode the stream correctly.
Still haven't figured out a way, to create my own sample of xHE-AAC encoded audio. AFAIK, there are no encoders freely available, etc.
There's also a /rh.x16 stream with a content type of "audio/usac". So perhaps that is the /actual/ xHE-AAC stream?
I can't play the stream, with anything that I tried. I get errors like:
[aac_latm @ 0x4e82f80] Audio object type 42 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
(in case of mpv, I'm getting the exact same message, except with [ffmpeg/audio] in the beginning)
So perhaps 42 is the AOT for xHE-AAC, and it's simply not implemented anywhere (specifically ffmpeg)?
I don't think ffmpeg can decide xhe-aac.
Is there any sort of player available, for Windows or Linux, that can play xHE-AAC / USAC streams?
The only thing I can find is this: https://www.indexcom.com/products/hifiradio/
So that's an iOS app, only, it seems.
I'd at least want to have a listen, and see for myself, then.
For me this format is beyond useless.
Almost nothing supports it, impossible to encode unless you pay big bucks for a hw encoder.
Seems like patent hell caught this one.
https://trac.ffmpeg.org/wiki/Encode/AAC
https://trac.ffmpeg.org/wiki/Encode/AAC
ffmpeg supports HE-AAC, not xHE-AAC.
Guys, you're wasting your time on something that will not happen. xHE-AAC won't be publicly available.
And sincerely Opus does everything what xHE-AAC could do. Also new version of Opus 1.3 will be this year (I guess) which will bring even more of quality improvements.
P.S. Why asking for something expensive while there is a patent-free format freely available which does the same job?
Better quality at extremely low bitrates as 16-32 kbps stereo? Well, that's it, xHE-AAC could shine only there by design. It's very slightly better than [HE]AAC at higher bitrate and no better than Opus. ( I had chance to listen a reference xHE-AAC at 96 kbps and it was inferior to state of art Apple AAC encoder at 96 kbps . However it was slightly better than HE-AAC at 64 kbps and considerably better than HE-AACv2 at 32 kbps.
xHE-AAC is a sort of HE-AACv3 with a very few real changes at higher bitrate such as slightly better lossless entropy coder and better stereo coding ( ~+8 kbps of compression gain).
P.S2. If they aren't interested in making xHE available as software encoder well, then good for them. Just show middle finger and move to something better ... good news we have a good alternatives. :)
Well, I can only go by the examples and sound bites that got released for the press, etc.
It's not that I'm "longing" for this codec to any extent. But to me, it seems xHE-AAC closes a gap - for now, at least.
What is the gap? Well, it's the gap between I'd say ~48kb/s Opus, and <3kb/s speech codecs like Codec2, that has seen some quite remarkable improvements over the last couple months:
http://www.rowetel.com/?p=5966
and: https://storage.googleapis.com/downloads.webmproject.org/icassp2018/index.html
Now you might ask the question of reason behind closing that gap. And yes, you might bring up simply the reason of there not really being any market for it. But from a scientific and engineering standpoint, I don't think this is a fruitless endeavor.
If we can trust the sound bites and samples we get from the marketing division of FhG, xHE-AAC is quite amazing sounding in the 8kb/s-16kb/s range.
Before xHE-AAC gets released, I believe we'll simply see someone pick up a project of making a free codec working in these bitrates, though. I believe that's more likely to happen any time soon.
Marketing wise, there's no reason for FhG to release the codec to anyone but hardware manufacturers. There's no marketable reason to be able to listen to xHE-AAC streams on your cellphone or whatever. It's so niche, almost Codec2 levels of niche. So, I don't think well ever see encoders or decoders plonked down on us for "home use".
...
Marketing wise, there's no reason for FhG to release the codec to anyone but hardware manufacturers. There's no marketable reason to be able to listen to xHE-AAC streams on your cellphone or whatever. It's so niche, almost Codec2 levels of niche. So, I don't think well ever see encoders or decoders plonked down on us for "home use".
True.
I'd like to encode some audiobooks in 8kbps to see if it holds. As well as test if 24kbps stereo is any better than he aac v2. Totally non-commercial.
About codec2 hold your breath because we have now parametric-WaveNet, basically codec2 at 2.4Kbps decoded using a wavenet model.
https://arxiv.org/abs/1712.01120
https://storage.googleapis.com/downloads.webmproject.org/icassp2018/index.html
Phantom_13 thank you for the link.
This is a game changer. New parametric-WaveNet@2.4 kbps sounds as good as high quality WB speech codec@ 8 kbps (if not even better)
:o
http://www.rowetel.com/?p=5966
It shouldn't be difficult to scale this codec to fullband and stereo. This way fullband, stereo speech with near transparent quality would be possible at ~ 8 kbps. Amazing.
@Phantom_13 Well, yeah, that's what I was linking to. In fact that's how I've kinda stumbled over this.
The highest compression currently usable with Codec2 is 700C. There seems to be some talks of using param WaveNet to decode Codec2 in 700C mode (700b/s).
About codec2 hold your breath because we have now parametric-WaveNet, basically codec2 at 2.4Kbps decoded using a wavenet model.
https://arxiv.org/abs/1712.01120
https://storage.googleapis.com/downloads.webmproject.org/icassp2018/index.html
WOW that's some serious audio black magic and witchcraft!
Makes me wonder if the idea of deep machine learning could be applied on a general purpose codec (instead of just speech codec) to achieve a similar efficiency ratio.
Deep machine learning is really revolutionarizing computing as we knew it up until now.
I think xHE-AAC is ready to rock! I run 4 Internet Radio stations and all 4 have xHE-AAC streams (as well as 64kbps HE-AACv1, 320 kbps AAC stereo and 320kbps AAC 5.1 Surround streams). The encoders I use are software called StreamS Hi-Fi Encoders running on a Windows 10 Pro PC. The same PC is also running Orban Optimod PCn audio processing. Output from the Orban travels via Virtual Audio Cables to the StreamS Encoders.
I have both legacy Icecast and HLS streams running. At the moment StreamS Hi-Fi Radio for iOS and tvOS is the only player I'm aware of that can play the xHE-AAC streams. Last year Via Licensing changed the terms for xHE-AAC making it freely available to all existing AAC licensees which should encourage development of a lot more xHE-AAC players on various platforms.
My main xHE-AAC streams are 40kbps (average bit-rate) 48kHz sampling rate HLS format and are listed in the StreamS Hi-Fi Radio app directory. I also have 32kbps (constant bit-rate) 48kHz sampling rate Icecast format xHE-AAC streams for testing purposes. I think the 32kbps streams sound very good but to my ears 40kbps is the sweet spot for achieving true high-fidelity sound. Others' opinions may vary.
I archived a bit over half an hour of one of my stations off the 40kbps xHE-AAC HLS feeding my iPhone running StreamS Hi-Fi Radio to my Mac using AirPlay and Airfoil Satellite (on May 7th 2018 starting at 5:48 pm Pacific). I then output Airfoil Satellite to a virtual audio device with an app called Loopback and then recorded that with Audio Hijack in Apple Lossless Codec format (48kHz sampling rate). AirPlay also uses Apple Lossless Codec so the resulting recording should provide an accurate listening experience comparable to hearing the live broadcast with the iPhone app.
Anyone interested in this listening experience can download the file at this URL: LG73 xHE-AAC Sample in Apple Lossless Codec (zip format) (https://www.lg73.ca/xHE-AAC_Airchecks/LG73_40k_xHE-AAC_20180507_1748.zip). The download will be available for a limited time. Anyone who has StreamS Hi-Fi Radio for iOS and tvOS can find my four xHE-AAC streams in the app directory and experience the xHE-AAC streams live. The stations are LG73.CA (https://www.lg73.ca), MaxRadio.CA (https://www.maxradio.ca/), NewWestRock.CA (https://www.newwestrock.ca/) and UptownRadio.CA (https://www.uptownradio.ca/). Formats are Pop, Eclectic, Classic Soul and Classic Rock respectively. At the moment all four stations are running identical Optimod settings.
I may be considered a blasphemer around these parts for saying the following (seems like there are a lot of open source fans here), but I believe xHE-AAC is the best codec for any stream running between 8kbps and 40kbps bitrate. I've done some extensive testing with Opus (v1.2.1 encoder in the app LadioCast) and found it was tolerable at 48kbps but even at that higher bit-rate to my ears was inferior to 40kbps xHE-AAC. At 40kbps and below I found Opus v1.2.1 was unacceptable. I have no experience yet with "Codec" or with Opus v1.3 beta.
Regards,
Phil
Well, we kinda identified the application is very niche. So that kinda proves the point.
However, I'd like to know where you got your encoders from, and whether these are the xHE-AAC hardware encoders or just a program running on (presumably) a Windows computer.
Codec2 isn't geared to be a general-purpose codec. It's specifically geared to be a speech codec for extremely band-limited channels. It tries to be better than analog SSB, the target is legibility, not audio quality in the sense like music transparency, etc.
Guys, you're wasting your time on something that will not happen. xHE-AAC won't be publicly available.
Some good news,
https://www.businesswire.com/news/home/20180608005558/en/Fraunhofer%E2%80%99s-xHE-AAC-Audio-Codec-Software-Extends-Native
ERLANGEN, Germany--(BUSINESS WIRE)--With the release of the Android P beta 3 preview, Fraunhofer IIS announces a new version of the popular FDK library which has been a part of Android since 2012. The FDK2 version will bring several new technologies to Android OEMs, service providers and developers, including xHE-AAC for video and music delivery down to 12kbit/s for stereo sound and MPEG-D DRC dynamic range control for better listening in noisy environments.
Finally it will be possible to do public listening tests comparing Opus and xHE-AAC. Also being open source, it will guarantee support for the codec regardless of its commercial future,
Hi, Ivan,
I should eat my own words now. I admit it :)
In other hand You as developer know better than anyone else that everything will depend on encoder.
FDK is known to be somewhat inferior to Apple and FhG (Winamp) (HE)-AAC encoders. Whether FDK xHE-AAC will be superior or not to extremely well tuned AAC encoders is still question.
Competition is welcome anyway!
Finally it will be possible to do public listening tests comparing Opus and xHE-AAC
Agree. Especially now when new version of Opus 1.3 will be released soon.
For me, it would be interesting to see how much impact in quality remains at such low bit-rates between "good enough" codec implementations where large part of the spectrum is parametrically generated, not transform-coded.
But for that we'd need more than one available implementation of xHE-AAC.
There's maybe also some potential to exploit temporal self-similarity. In music, many sounds are often repeated with minimal changes. Sometimes even without any changes (samples, techno, etc).
So far I haven't heard of any codec which uses it and actually works.
Just a note, with the release of android pie the repository is updated with FDK2 source including the goodies for xhe-aac.
Awesome, can't wait till we have some win32 binaries
https://www.iis.fraunhofer.de/en/pr/2018/20180608_AME_Android.html
Fraunhofer’s xHE-AAC Audio Codec Software Extends Native AAC Support In Android P For Better Quality At Low Bit Rates
/ 8.6.2018
Well, now it has come: https://android.googlesource.com/platform/external/aac/
Has anybody seen it?
I'm afraid xHE-AAC support is DECODER ONLY in FDKv2.
As for encoder side, AAC-ELDv2 seems to be added, which seems to be activated by specifying special channel mode for it.
Well, now it has come: https://android.googlesource.com/platform/external/aac/
Has anybody seen it?
I'm afraid xHE-AAC support is DECODER ONLY in FDKv2.
As for encoder side, AAC-ELDv2 seems to be added, which seems to be activated by specifying special channel mode for it.
Decode only... That sucks :(
Well, having xHE-AAC for decode-only kinda makes sense.
xHE-AAC isn't a low-delay codec, so for telephony, etc. it's not really suitable. The only thing it was used for in my corner of the world, was DRM (Digital Radio Mondiale), which failed and got cancelled.
AAC-ELD is a low-delay codec, so using that for telephony makes sense, and that's why they put encoders into Android.
https://www.iis.fraunhofer.de/en/ff/amm/prod/kommunikation/komm/aaceld.html <-- I gotta say, it's kinda funny and sad how they don't include Opus in their little graphs, there.
https://www.iis.fraunhofer.de/en/ff/amm/prod/kommunikation/komm/aaceld.html <-- I gotta say, it's kinda funny and sad how they don't include Opus in their little graphs, there.
Because AAC-ELD v1/v2 is old, outdated and outperformed by Opus, EVS and low delay 3DA.
Because AAC-ELD v1/v2 is old, outdated and outperformed by Opus, EVS and low delay 3DA.
Do we have any stats on that?
AAC-ELD doesn't seem to be
that old, the first release is from 2008: https://www.iso.org/standard/46457.html
Work on EVS started in 2008 and it hasn't been finalized yet, iirc.
Also, it seems EVS is gonna be patent-pool'd by MPEG-LA.
As to MPEG-H low-delay 3DA, I know only of a couple talks and presentations, I've never seen anything practical happening with low-delay 3DA so far.
AAC-ELD uses low delay SBR and PS which are 14-15 years old.
AAC-(ELD) vs Opus
Opus has outperformed AAC family codecs with long delay settings. Obviously AAC-ELD will be worse than Opus with low delay settings.
AAC-ELD vs EVS
EVS is superior to AAC-ELD by definition.
EVS is a successor of AAC-ELD and AMR families. EVS is mentioned as low delay USAC/xHE-AAC which is based on enhanced versions of AAC and AMR in whitepapers.
EVS core format has been already approved as a standard in December 2014 and already implemented by some carriers. There are some extensiones going through standardization.
P.S. There is also very interesting and useful site http://www.ecodis.de/audio.htm by Chris H. Some information about last generation audio codecs can be found there.
There's an encoder available for testing:
exhale - xHE-AAC encoder (https://hydrogenaud.io/index.php?topic=118888)
Compile it yourself for Windows or Linux or your favorite Unix-alike. Aims for medium* to high* bitrate targets:
- high bit-rates those at and above the sweetspot of (1990s) MPEG-2 AAC-LC, i.e., 128 kbit/s stereo
- medium bit-rates those at and above the sweetspot of (2000s) HE-AAC, i.e., 64 kbit/s stereo, up to 128 kbit/s stereo
I'm catching up on posts right now, and this kinda caught my eye just now.
xHE-AAC for "medium to high" bitrate targets is a bit odd to me, as xHE-AAC is supposed to be used at very low bitrates. It's used in very narrow bandwidth digital radio, etc.
I'll definitely try it and see how it performs and how it sounds.
Also: finally ¦D
@polemon Please read the more recent posts. For this instance of "medium to high", "medium" is about 96-112kbps, and "high" is "128+" kbps.
So, it's attempting to compete with maybe Opus at mono and stereo encoding.
Note that his current encoder doesn't use any form of SBR, so it's not really going to be able to drop much below 48kbps per channel without either reducing the sample rate comparable to LC AAC, or impacting the quality significantly.
There seems to be an encoder out there. Or is this only a port of the open source exhale?
https://www.poikosoft.com/xhe-aac-converter
xHE-AAC
Exhale 1.0.7
https://gitlab.com/ecodis/exhale
https://www.poikosoft.com/music-converter-encoder-versions
By the way, I found a graphical user interface for the exhale command-line encoder, for those not using foobar2000 or the above:
https://github.com/moisespr123/exhale-gui/
I recently read that Netflix are rolling out xHE-AAC in their Android app, to take advantage of MPEG-D DRC to do Loudnedd management.
https://netflixtechblog.com/optimizing-the-aural-experience-on-android-devices-with-xhe-aac-c27714292a33?gi=244064d0be08
New audio codec MPEG-H 3D will be probably supported in Android 12.
https://www.xda-developers.com/google-sony-360-reality-audio-support-android/
MPEG-H 3D brings new multi-channels modes and some new compression tools on top of xHE-AAC/USAC like IGF (which finally replaces [e]SBR) and some other interesting improvements.
All of which may be really useful for the latest in excessive speaker count surround systems.
Sony 360 Reality Audio currently requires the music provider to explicitly support it, as well as compatible speakers or headphones
How will the "compatible headphones" differ from normal headphones? Wont it just render it for 2 channel headphones?
There are some real multichannel headphones https://www.headphonedungeon.com/guide-to-surround-sound-headphones/
Also MPEG-H 3D Audio will be great for new modes like 5.1, 7.1 ... 22.2 channels, including some comments or height channels, without increasing too much bandwidth for Netflix, etc.