IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
APT-X
slenpree
post Jan 27 2010, 12:16
Post #1





Group: Members
Posts: 14
Joined: 5-October 07
Member No.: 47605



see www.aptx.com

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.

Of course I will share my results on here biggrin.gif

Kind Regards,
Jonathan
Go to the top of the page
+Quote Post
smack
post Jan 27 2010, 16:18
Post #2





Group: Members
Posts: 187
Joined: 16-January 02
Member No.: 1046



Look at the documents available at the download section of their website for more details.

Their codecs use subband ADPCM. They say the advantages of their technology are low latency, full frequency bandwidth and no quality degradation when MP3 or AAC data is transcoded.

The compression ratio of apt-X Standard, Enhanced and Bluetooth is fixed at 4:1. Thus 128 kbps apt-X encodes 16 bits stereo at a sample rate of 16 kHz. This shouldn't be difficult to ABX with regular "CD quality" music...
Go to the top of the page
+Quote Post
slenpree
post Jan 27 2010, 16:58
Post #3





Group: Members
Posts: 14
Joined: 5-October 07
Member No.: 47605



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

This post has been edited by slenpree: Jan 27 2010, 16:59
Go to the top of the page
+Quote Post
dtrainor
post Jan 27 2010, 17:17
Post #4





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593




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!

Regards,
David
Go to the top of the page
+Quote Post
smack
post Jan 27 2010, 17:23
Post #5





Group: Members
Posts: 187
Joined: 16-January 02
Member No.: 1046



QUOTE (slenpree @ Jan 27 2010, 16:58) *
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.
Go to the top of the page
+Quote Post
pdq
post Jan 27 2010, 18:45
Post #6





Group: Members
Posts: 3421
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



QUOTE (dtrainor @ Jan 27 2010, 12:17) *
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!

Regards,
David

Welcome to HA. smile.gif
Go to the top of the page
+Quote Post
slenpree
post Jan 27 2010, 19:08
Post #7





Group: Members
Posts: 14
Joined: 5-October 07
Member No.: 47605



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

Regards,
Jonathan

This post has been edited by slenpree: Jan 27 2010, 19:32
Go to the top of the page
+Quote Post
Woodinville
post Jan 27 2010, 20:32
Post #8





Group: Members
Posts: 1402
Joined: 9-January 05
From: JJ's office.
Member No.: 18957



QUOTE (dtrainor @ Jan 27 2010, 08:17) *
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.


Cool, I wonder what kind of filters you guys used. smile.gif smile.gif smile.gif


--------------------
-----
J. D. (jj) Johnston
Go to the top of the page
+Quote Post
Garf
post Jan 27 2010, 20:54
Post #9


Server Admin


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



Sounds like the area in which CELT is competing, too.
Go to the top of the page
+Quote Post
dtrainor
post Jan 27 2010, 23:01
Post #10





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593



QUOTE (slenpree @ Jan 27 2010, 18:08) *
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

This post has been edited by dtrainor: Jan 27 2010, 23:13
Go to the top of the page
+Quote Post
dtrainor
post Jan 27 2010, 23:10
Post #11





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593



QUOTE (Garf @ Jan 27 2010, 19:54) *
Sounds like the area in which CELT is competing, too.


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!

Regards,
David
Go to the top of the page
+Quote Post
smack
post Jan 28 2010, 09:53
Post #12





Group: Members
Posts: 187
Joined: 16-January 02
Member No.: 1046



QUOTE (slenpree @ Jan 27 2010, 19:08) *
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.
Go to the top of the page
+Quote Post
dtrainor
post Jan 28 2010, 11:20
Post #13





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593



QUOTE (smack @ Jan 28 2010, 08:53) *
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.

Regards,
David
Go to the top of the page
+Quote Post
skamp
post Jan 29 2010, 07:30
Post #14





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
dtrainor
post Jan 29 2010, 11:31
Post #15





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593



QUOTE (skamp @ Jan 29 2010, 06:30) *
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.

Regards,
David
Go to the top of the page
+Quote Post
skamp
post Jan 29 2010, 17:26
Post #16





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (dtrainor @ Jan 29 2010, 11:31) *
However, we are working directly with a company on a product that will have this capability.

Thanks. I can't think of a better solution to use my favorite wired headphones with decent wireless audio. Would you mind letting us know of the product when it's out?


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
dtrainor
post Jan 29 2010, 20:46
Post #17





Group: Members
Posts: 8
Joined: 27-January 10
Member No.: 77593



QUOTE (skamp @ Jan 29 2010, 16:26) *
Thanks. I can't think of a better solution to use my favorite wired headphones with decent wireless audio. Would you mind letting us know of the product when it's out?


Sure, no problem.
Go to the top of the page
+Quote Post
jmvalin
post Feb 23 2010, 00:16
Post #18


Xiph.org Speex developer


Group: Developer
Posts: 482
Joined: 21-August 02
Member No.: 3134



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.
Go to the top of the page
+Quote Post
smartfinder
post Jun 19 2010, 21:38
Post #19





Group: Members
Posts: 2
Joined: 19-June 10
From: Chile Valparaiso
Member No.: 81645



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.

PD: I'm from Chile and read the forum since 2004

This post has been edited by smartfinder: Jun 19 2010, 21:56
Go to the top of the page
+Quote Post
slenpree
post Jul 11 2010, 23:19
Post #20





Group: Members
Posts: 14
Joined: 5-October 07
Member No.: 47605



QUOTE (jmvalin @ Feb 22 2010, 23:16) *
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?

-Jonathan
Go to the top of the page
+Quote Post
smallicoat
post Sep 9 2010, 22:09
Post #21





Group: Members
Posts: 1
Joined: 9-September 10
Member No.: 83743



QUOTE (dtrainor @ Jan 27 2010, 14:01) *
QUOTE (slenpree @ Jan 27 2010, 18:08) *
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
Go to the top of the page
+Quote Post
lbbrhzn
post Oct 1 2010, 16:20
Post #22





Group: Members
Posts: 2
Joined: 1-October 10
Member No.: 84268



QUOTE (Woodinville @ Jan 27 2010, 20:32) *
QUOTE (dtrainor @ Jan 27 2010, 08:17) *
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.


Cool, I wonder what kind of filters you guys used. smile.gif smile.gif smile.gif


See: http://www.aptx.com/Documents/White-Papers...PCM-coding.aspx

for more info.

Go to the top of the page
+Quote Post
lbbrhzn
post Oct 1 2010, 16:25
Post #23





Group: Members
Posts: 2
Joined: 1-October 10
Member No.: 84268



QUOTE (dtrainor @ Jan 27 2010, 23:01) *
QUOTE (slenpree @ Jan 27 2010, 18:08) *
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



See https://ics.cs.uni-tuebingen.de/publication...ers/lcn2010.pdf for a comparison of SBC, CELT, APT-X, ULD based on PEAK - ODG
Go to the top of the page
+Quote Post
saratoga
post Oct 1 2010, 16:30
Post #24





Group: Members
Posts: 5043
Joined: 2-September 02
Member No.: 3264



QUOTE (lbbrhzn @ Oct 1 2010, 11:20) *
QUOTE (Woodinville @ Jan 27 2010, 20:32) *
QUOTE (dtrainor @ Jan 27 2010, 08:17) *
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.


Cool, I wonder what kind of filters you guys used. smile.gif smile.gif smile.gif


See: http://www.aptx.com/Documents/White-Papers...PCM-coding.aspx

for more info.


Thats a great resource. Thanks.
Go to the top of the page
+Quote Post
atlantic
post Jun 27 2011, 15:05
Post #25





Group: Members
Posts: 3
Joined: 11-September 10
Member No.: 83789



QUOTE (dtrainor @ Jan 29 2010, 11:31) *
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.

Best Regards,
atlantic
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
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: 22nd October 2014 - 17:33