this company really annoys me because although they claim APT-X to be so great (near lossless @ 128kbps) there is little evidence to support this claim due to their proprietary nature and hardware focus. Their main codec seems to be common in hardware ISDN codecs due to low delay which suggests low complexity.

All in all I would like to give these folks a chance, they might have some very intelegent (and expensive) sound scientists backing the project. It's come the time where I would like to do some blind listening tests with this codec because with all the focus on MP3 ( and even AAC ) I doubt I will be blown away when comparing it a 128kbps MP3.

However I can't find an APT-X software codec for foobar, or at all. With all the game codec packs for foobar I was quite suprised not to see APT-X as it's been about for quite a while. Perhaps I'm just not looking hard enough and need to use the chinese google. If anyone could save my alot of time and point out the foo_input_aptx component that would be greatly appreciated.

thanks for pointing me in the right direction smack, I didn't realise with ADPCM the bitrate reflected the sample rate, that would explain why the ISDN APT-X codecs I have briefly worked with set themselves to 16Khz when you open two ISDN channels ( 2x 64Kbps ).

Does your last statement mean a regular ADPCM audio file @ 128kbps would be close enough to APT-X for doing a blind listening test against MP3, AAC etc...

After a bit more research I also found that the cinema version of DTS uses ATP-X Standard/100 on a CD and the 35mm film has only the timecode

As someone who works for APTX, hopefully I can shed a little extra light here. Responding to Jonathans post, I think there are a few points I'd like to bring out. Our codecs tend to be used in applications where use of codecs such as MP3, AAC, etc is problematic or prohibitive. Such areas include extremely low codec latency, very low complexity and low-power operation, very high resilience to audible effects cause by unreliable networks, ease of real-time streaming, etc. Of course we have to try to keep high sonic quality too! As such, a simple quality comparison with MP3 (for example) at some determined bit-rate doesn't really reflect the value of what we do. It wouldn't be an apples-to-apples comparison. Of course some of our literature has to try to compare and contrast what we do with MP3, AAC, etc purely because it's always the first question that we get asked :-)

smack is correct that several of our codecs (in particular the ones that have been around for a while) are based on sub-band ADPCM principles with some special sauce of our own. Some of our newer codec designs have moved away from this general architecture, in particular our lossless codec and a scalable codec that we have under development.

For me, the plus side to all this is that it has spurred me to set up an account here and now I'll get to enjoy the community!

Does your last statement mean a regular ADPCM audio file @ 128kbps would be close enough to APT-X for doing a blind listening test against MP3, AAC etc...

No need to use another ADPCM codec. Just use a regular 16 bits stereo PCM file (WAV of AIFF) downsampled to 16 kHz. This PCM file (@ 512 kbps) has a higher audio quality than the 128 kbps apt-X would have.

thanks smack, i'll give that a go later and report my results. I've ignored the shanon nyquist theorm before and encoded at 22.05Khz, it sounded absolutely terrible (worse than what i've heard of apt-x but I think that is because apt-X "predicts"?) - though I don't remember which codec it was now.

Welcome to hydrogen audio dtrainor, it's good to speak to someone from apt-X! I work with live audio over satellite a bit, but using UDP/IP based systems and not the usual ISDN based systems, as such AAC seems to be more popular than apt-x with the people I speak to.

Continuing on from you said about low delay and low complexity. Can you refer me to any literature comparing and contrasting the sonic ability of apt-X against the Enhanced Low-Delay AAC at the same bit-rates (assuming very similar delays here). I now understand the two codecs have a different architecture and AAC is probably not so feasable on a hardware based DSP.

But just for fun I would really enjoy some time with a trial version of a apt-X software encoder/decoder UPDATE: converted a FLAC rip of a CD to 16Khz LPCM and it sounds garbage for 512kbps. I should imagine the same test using "Sub-band ADPCM" would be more fair but it sounds like apt-X does add alot of sauce on top.

Continuing on from you said about low delay and low complexity. Can you refer me to any literature comparing and contrasting the sonic ability of apt-X against the Enhanced Low-Delay AAC at the same bit-rates (assuming very similar delays here). I now understand the two codecs have a different architecture and AAC is probably not so feasable on a hardware based DSP.

Regards,Jonathan

Jonathan,

I don't think we've any formal product literature that documents a formal AAC-ELD comparison. I'll check if I could post some of our internal test results to give some points of comparison. In terms of codec delay between AAC-ELD and the various apt-X codecs there's still quite a large proportional difference, although the absolute difference is obviously a lot less than with other AAC variants. I think Fraunhofer quotes a minimum algorithmic delay of around 15 ms for AAC-ELD whilst most of our codecs are 2 ms or less for 44.1 kHz sampling. Of course this very low delay prevents apt-X reaching the lower bit-rates of AAC-ELD, so it really is working at a different point of operation.

That's a fair point and at the lowest end of the CELT typical delay range (around 3ms) it's getting down to the sort of coding delays apt-X codecs would tend to operate at too. I think the underlying signal processing approaches are quite different however. That said, the CELT development is an interesting initiative. I guess with codec development the key point is to keep innovating as there is a lot of good work going on out there!

UPDATE: converted a FLAC rip of a CD to 16Khz LPCM and it sounds garbage for 512kbps. I should imagine the same test using "Sub-band ADPCM" would be more fair but it sounds like apt-X does add alot of sauce on top.

No, a 128 kbps apt-X file encoded from that 512 kbps PCM file would not sound better. There is no special magic potion that creates the lost bits out of thin air. I know that there are techniques like SBR that appear to do just that, but apt-X does not use it. (or does it and I missed it?)

Btw. apt-X Bluetooth uses a bitrate of 352 kbps and thus preserves the full bandwidth of a 16 bits stereo 44 kHz audio stream. That's a lot more reasonable for "Hi-Fi" applications.

No, a 128 kbps apt-X file encoded from that 512 kbps PCM file would not sound better. There is no special magic potion that creates the lost bits out of thin air. I know that there are techniques like SBR that appear to do just that, but apt-X does not use it. (or does it and I missed it?)

Btw. apt-X Bluetooth uses a bitrate of 352 kbps and thus preserves the full bandwidth of a 16 bits stereo 44 kHz audio stream. That's a lot more reasonable for "Hi-Fi" applications.

smack is correct that there is no SBR or similar technique at work here. Of course SBR is not creating from thin air either, as the higher frequencies are approximately reconstructed from the lows/mids plus some low-rate parametric information in the coded format. The quoted values for apt-X Bluetooth are also accurate. Of course the principal codec for comparison here is the Bluetooth SBC codec rather than MP3, AAC, etc. Our Bluetooth codec competes against SBC primarily on audio quality and (to a lesser extent) delay and error resilience.

dtrainor: do you know of any Bluetooth emitter + receiver set that makes use of apt-X, where the emitter can be plugged into a 1/8" jack (regular audio output) and where a pair of wired headphones can be plugged into the receiver?I was looking into apt-X after I found out just how much SBC sucked but couldn't find a practical solution.

dtrainor: do you know of any Bluetooth emitter + receiver set that makes use of apt-X, where the emitter can be plugged into a 1/8" jack (regular audio output) and where a pair of wired headphones can be plugged into the receiver?I was looking into apt-X after I found out just how much SBC sucked but couldn't find a practical solution.

That's a good question. I believe that Sennheiser produced (or is the process of producing) an apt-X Bluetooth emitter that plugs into a 1/8" jack that is compatible with their apt-X Bluetooth headphones (PX 210 BT and PXC 310 BT, currently). However I don't seem to be able to find any online availability for this emitter and their website only mentions the iPod and USB versions. AFAIK there isn't an apt-X Bluetooth receiver with a conventional headphone socket currently available. However, we are working directly with a company on a product that will have this capability. It's probably a few months away from commercial release.

As far as I understand (but I could be wrong), the 2 ms APT-X delay is just the look-ahead, so if you're packetizing, the delay will be more than that. I expect you'll be able to do at least as good with CELT. One other thing to keep in mind is that APX-X is mainly targeted at wireless (non-IP) links and CELT is mainly targeted at IP transmission. That being said, CELT can work on wireless links and I'm sure APT-X can work on IP. Note, that all of this info is guesswork from the APT-X website. I haven't actually tested it myself.

Hi all, I like the codecs long ago, I would like to share an idea about ADPCM

Seeking to understand APT-X 100 and in my desperation to hear well in ADPCM,lossyWAV use (-q 1) as a filter and then compressed in IMA-ADPCM,He obtains results in an artifact-free audio compression typical of ADPCM,I am satisfied with this test for the quality of sound.

Researching the cinema 882Kbps DTS audio, use APT-X 100, a more effective ADPCM,perhaps simulating their behavior in this test.

As far as I understand (but I could be wrong), the 2 ms APT-X delay is just the look-ahead, so if you're packetizing, the delay will be more than that. I expect you'll be able to do at least as good with CELT. One other thing to keep in mind is that APX-X is mainly targeted at wireless (non-IP) links and CELT is mainly targeted at IP transmission. That being said, CELT can work on wireless links and I'm sure APT-X can work on IP. Note, that all of this info is guesswork from the APT-X website. I haven't actually tested it myself.

Sorry to bring up an old topic but in response to that, I had recently came across APT-X 100 working across an IP link!

I had it demonstrated to me from one of the major ISDN codec manufacturers...But was cruious what licensing implications this had. i.e. Wireshark?

Continuing on from you said about low delay and low complexity. Can you refer me to any literature comparing and contrasting the sonic ability of apt-X against the Enhanced Low-Delay AAC at the same bit-rates (assuming very similar delays here). I now understand the two codecs have a different architecture and AAC is probably not so feasable on a hardware based DSP.

Regards,Jonathan

Jonathan,

I don't think we've any formal product literature that documents a formal AAC-ELD comparison. I'll check if I could post some of our internal test results to give some points of comparison. In terms of codec delay between AAC-ELD and the various apt-X codecs there's still quite a large proportional difference, although the absolute difference is obviously a lot less than with other AAC variants. I think Fraunhofer quotes a minimum algorithmic delay of around 15 ms for AAC-ELD whilst most of our codecs are 2 ms or less for 44.1 kHz sampling. Of course this very low delay prevents apt-X reaching the lower bit-rates of AAC-ELD, so it really is working at a different point of operation.

Regards,David

David,I am trying to find Bluetooth modules with your apt-x technology, and am hopeful that CSR might be a good fit...they have their logo on the apt-x web page so I assume that they enjoy a closer relationship than e.g. Bluegiga or Laird as a partner. Best wishes,Sam

Continuing on from you said about low delay and low complexity. Can you refer me to any literature comparing and contrasting the sonic ability of apt-X against the Enhanced Low-Delay AAC at the same bit-rates (assuming very similar delays here). I now understand the two codecs have a different architecture and AAC is probably not so feasable on a hardware based DSP.

Regards,Jonathan

Jonathan,

I don't think we've any formal product literature that documents a formal AAC-ELD comparison. I'll check if I could post some of our internal test results to give some points of comparison. In terms of codec delay between AAC-ELD and the various apt-X codecs there's still quite a large proportional difference, although the absolute difference is obviously a lot less than with other AAC variants. I think Fraunhofer quotes a minimum algorithmic delay of around 15 ms for AAC-ELD whilst most of our codecs are 2 ms or less for 44.1 kHz sampling. Of course this very low delay prevents apt-X reaching the lower bit-rates of AAC-ELD, so it really is working at a different point of operation.

AFAIK there isn't an apt-X Bluetooth receiver with a conventional headphone socket currently available. However, we are working directly with a company on a product that will have this capability. It's probably a few months away from commercial release.

Regards,David

Hi David,

Can you tell more about this apt-X Bluetooth receiver with a conventional headphone socket? Has it been released by now?

I'm looking for an apt-X Bluetooth capable receiver that could be used with my mobile audio setup (audio fed from mobile phone to IEMs). The receiver would have to be battery powered and relatively lightweight. The upcoming Nokia N9 transmits apt-X Bluetooth.