[SubMash]

Here's the data for 17.5KHz.



It might be clipping noise by digital saturation.

0 dB Full-Scale tone through CSR solution seems to make mathematical saturation resulting harmonics and clipping noise. (Green Circle)

When you get the source volume or the digital volume at the sink a just little bit lower -0.25dB to -0.5dB,
those harmonics by saturation would be removed.

I'm not sure which CSR solution Nokia aptX receiver has,
but it may use the digital volume control or may not maintain the full-precision of the atpX decoded stream.
Eventually, there might be no clipping noise.

Here' another example with AAC on CSR.



It shows huge harmonics at 0dBFS.
When you get any of digital volume lower by -0.25dB, you can get clean tone from CSR AAC.

ES100 internally use analog volume, that might be the difference.
Getting lower down the source volume would show some different result, I guess.
And make sure the analog volume above +2dB will overdrive the output resulting another saturation on the amplifier.
(ES100 max. output power specified at +2dB)

We've already been aware of the above saturation issue for many years,
and many worldwide top-tier makers, we've been working with, also know that as well.
But it's not likely happened to come up with 0 dBFS single tone with usual music tracks.

I would say the above issue cause no problem at all with any music tracks.

One last thing I'd like to let you know is that:

Any music tracks are not likely to have such a huge energy in the high-frequency region unless otherwise, it's just white noise.

As you can see the below plots,
The -1dB tone at 17.5KHz is not likely to encoded correctly because it's too big for aptX.
While -12dB tone at the same frequency seems to be managed by aptX.
Hope this helps you.




Thanks and Regards,
WS

First of all - thanks for investigation and explanation, I appreciate.

Clipping - is overflow. Unfortunately, I can hear it in a normal music. Certainly, it's not as bad as with synthetic tests, but enough to distract.
I don't know how it's possible for Nokia to decrease digital volume before CSR - there is no Nokia before CSR available - the same source sending with same digital volume.
So it has to be something after CSR. I already saw that manipulation with EQ brings the same noise with 48kHz high impedance load and I assume it is after CSR.
So what is it?

It's useful info that above +2 analog volume would yield overdrive - it makes sense to mark it in the software, I guess.

All of that though is not about aliasing - aliasing is not about overflow. When aliasing meets overflow - it becomes extremely loud, but you can hear it all the time.
And here, again - AAC doesn't have it, Nokia doesn't have it. It's not an inherent part of APTX. And I believe it can be addressed.
So what's up with that? We can't discuss aliasing looking on a frequency response chart - spectrogram is necessary and spectrogram over sweep looks weird. Even if the sweep is not 0dBA.

I'm waiting for the splitter to do proper tests in a coming weekend.

 

[redogfizbal]

Unsubscribing, submash is seriously needing a girlfriend.

 

[p50kombi]

Unsubscribing, submash is seriously needing a girlfriend.

Just put him on your ignore list, I did and its ever so quiet, except for the useful info

 

[veraideishal]

I am very sorry. My previous post here had serious methodological errors.

 

[antdroid]

Hi @wslee seeing as you're online would you mind telling me how long the short MMCX cables that were originally sold with the ES100 kickstarter were please? I need to get one made up but not sure what the ideal length is.

Thanks!

I made a 2 foot cable for my iSine and it’s a great length for travel. Fiio makes a short cable for mmcx that’s a little longer than that I think. You can also search Ali express for short ear phone cable and some hits will show up with finished products or diy ones. Very easy to make with soldering iron and the connectors. I made a balanced cable for a few dollars.

 

[waynes world]

I bet it’s Samsung devices . My old Galaxy S5 refused to play 44.1kHz when I used a USB DAC with it. Sometimes it wouldn’t even output the correct sample rate, and audio would sound half-speed and half-pitched.

I wonder why anyone would want to use the ES100 as a USB DAC off of a phone? The trade off of "a bit better SQ for much inferior convenience and functionality" isn't worth it for me. I previously got the zuperdac to connect to my old S5, and although it sounded great, it was a pain for many reasons. I find that BT receivers like the BTR1 - and even more so the ES100 - sound so good and provide such better functionality that I doubt that I will ever hook up a USB DAC to my phone again. Well, I'll probably connect the ES100 to my S7 today "just to try it out", but that will probably be a one time deal. My 2 cents.

 

[veraideishal]

This is a new version of my aptX testing. The previous results were compromised due to serious methodological errors:

So, ffmpeg apparently has recently (like November 2017 recently; it's not even in the stable release yet) added an aptX encoder and decoder that was reverse-engineered from the binaries.
Without signing an NDA or similar from Qualcomm, this is as close as we mortals can get to a reference implementation.

To satisfy my curiosity, I decided to test it out and plot the results. I'm posting the procedure below so anyone else can follow along.

Software Used
Audacity 2.2.2
FFMPEG 20180227-fa0c9d6, 64-bit Windows, Static build

Procedure

1. In Audacity 2.2.2, I generated a chirp signal
   
   
   Start and End Frequency: 20Hz to 20kHz
   Bit depth, Sample rate, Channels: 24bits(signed)/44.1kHz/stereo
   Amplitude: 0.707 (-3dBFS)
   Chirp type: Linear
   Duration: 30.00 seconds​
   
   NOTE: I am generating the chirp using 24-bit signed PCM because that is the highest fixed-point PCM bit depth that Audacity allows me to choose.
   
   ADDITIONAL NOTE: I had also gone into Edit->Preferences->Quality and turned off all dithering, because otherwise the dither will shift the quantization noise in strange ways across the frequency range.
   
   
2. I exported this as a 32-bit signed PCM file (.wav) and encoded it into aptX with the following command:
   
   
   ffmpeg -i "C:\Input\chirp_in.wav" -codec aptx "C:\Output\chirp_out.aptx" -y​
   NOTE: I have exported the file as 32-bit signed PCM as that is the native bit depth the ffmpeg aptX encoder accepts as input.
   
   
3. I then decoded this aptX file back into 32-bit signed PCM with the following command
   
   
   ffmpeg -ar 44100 -codec aptx -i "C:\Output\chirp_out.aptx" -codec pcm_s32le "C:\Output\chirp_out.wav" -y​
4. I then imported both chirp_in.wav and chirp_out.wav into Audacity, and used the Spectrogram view.
   
   
   Spectrogram Scale: Linear
   MInimum Frequency: 0Hz
   Maximum Frequency: 22.05kHz
   Gain: 20dB
   Range: 160dB
   Frequency Gain: 0dB/dec
   Algorithm: Frequencies
   Window Size: 2048 samples
   Window type: Hanning
   Zero padding factor: 1​

The results are shown below. We can see that the original file already had very faint aliasing artifacts crossing the entire frequency range (in my previous test, which used 16-bit PCM as the export format, the aliasing was buried under quantization noise).
The decoded aptX shows the quantization noise changing across the frequency subbands (due to the nature of the codec), but also shows stronger aliasing components that are quite different from the input file's aliasing (see, for example the three intersecting chirps at the start of the file).
The aliasing is also stronger (red in chirp_out vs blue in chirp_in).
This seems to imply that an aptX encoder functioning perfectly according to specifications actually can create strong aliasing.

Given this, it is entirely possible that if the PCM data coming out of an aptX decoder has its least-significant bits truncated (or if dither is added), that the resulting quantization noise can bury the aliasing components. This was what @wslee suggested was happening with the Nokia aptX receiver.

 

[veraideishal]

I wonder why anyone would want to use the ES100 as a USB DAC off of a phone? The trade off of "a bit better SQ for much inferior convenience and functionality" isn't worth it for me. I previously got the zuperdac to connect to my old S5, and although it sounded great, it was a pain for many reasons. I find that BT receivers like the BTR1 - and even more so the ES100 - sound so good and provide such better functionality that I doubt that I will ever hook up a USB DAC to my phone again. Well, I'll probably connect the ES100 to my S7 today "just to try it out", but that will probably be a one time deal. My 2 cents.

I honestly have no idea why anyone would do it on a daily basis. My very specific use-case before was because I wanted to connect my phone to a crappy speaker system, and my DAC provided a higher-current output than the phone's native headphone jack.

 

[SubMash]

This is a new version of my aptX testing. The previous results were compromised due to serious methodological errors:

So, ffmpeg apparently has recently (like November 2017 recently; it's not even in the stable release yet) added an aptX encoder and decoder that was reverse-engineered from the binaries.
Without signing an NDA or similar from Qualcomm, this is as close as we mortals can get to a reference implementation.

To satisfy my curiosity, I decided to test it out and plot the results. I'm posting the procedure below so anyone else can follow along.

Software Used
Audacity 2.2.2
FFMPEG 20180227-fa0c9d6, 64-bit Windows, Static build

Procedure

1. In Audacity 2.2.2, I generated a chirp signal
   
   
   Start and End Frequency: 20Hz to 20kHz
   Bit depth, Sample rate, Channels: 24bits(signed)/44.1kHz/stereo
   Amplitude: 0.707 (-3dBFS)
   Chirp type: Linear
   Duration: 30.00 seconds​
   
   NOTE: I am generating the chirp using 24-bit signed PCM because that is the highest fixed-point PCM bit depth that Audacity allows me to choose.
   
   
2. I exported this as a 32-bit signed PCM file (.wav) and encoded it into aptX with the following command:
   
   
   ffmpeg -i "C:\Input\chirp_in.wav" -codec aptx "C:\Output\chirp_out.aptx" -y​
   NOTE: I have exported the file as 32-bit signed PCM as that is the native bit depth the ffmpeg aptX encoder accepts as input.
   
   
3. I then decoded this aptX file back into 32-bit signed PCM with the following command
   
   
   ffmpeg -ar 44100 -codec aptx -i "C:\Output\chirp_out.aptx" -codec pcm_s32le "C:\Output\chirp_out.wav" -y​
4. I then imported both chirp_in.wav and chirp_out.wav into Audacity, and used the Spectrogram view.
   
   
   Spectrogram Scale: Linear
   MInimum Frequency: 0Hz
   Maximum Frequency: 22.05kHz
   Gain: 20dB
   Range: 160dB
   Frequency Gain: 0dB/dec
   Algorithm: Frequencies
   Window Size: 2048 samples
   Window type: Hanning
   Zero padding factor: 1​

The results are shown below. We can see that the original file already had very faint aliasing artifacts crossing the entire frequency range (in my previous test, which used 16-bit PCM as the export format, the aliasing was buried under quantization noise).
The decoded aptX shows the quantization noise changing across the frequency subbands (due to the nature of the codec), but also shows stronger aliasing components that are quite different from the input file's aliasing (see the three intersecting chirps at the start of the file).
The aliasing is also stronger (red in chirp_out vs blue in chirp_in).
This seems to imply that, contrary to my previous test, aptX actually does create strong aliasing as an expected result of its proper functioning.

My guess is that, exactly as @wslee said, the Nokia aptX receiver used a lower bit-depth DAC, which means that quantization noise overwhelms the aliasing.

Something is wrong here - you have aliasing in the source file already and then it amplified during conversion? How is that about aptx then?

 

[veraideishal]

Something is wrong here - you have aliasing in the source file already and then it amplified during conversion? How is that about aptx then?

aptX did not amplify the existing aliasing: it created new artifacts. Note that the shape of the aliasing in the aptX decoded PCM is completely different and that the power is stronger.

With 24 bits of resolution, it is inevitable that truncation errors will cause low levels of harmonics to show up in the test signal, above the quantization noise floor (there is 144dB of dynamic range in 24 bits). And because of the Nyquist theorem, very high-frequency harmonics will be aliased back down.

The important thing to note is that the harmonics/aliasing are very, very low in the original signal (probably inaudible against the analog noise floor of the output stage), but that the aptX decoded output has a much higher aliasing-to-signal ratio (which, as we both know, we can hear).

You are welcome to repeat my test if you think I've missed something

 

[SubMash]

aptX did not amplify the existing aliasing: it created new artifacts. Note that the shape of the aliasing in the aptX decoded PCM is completely different and that the power is stronger.

With 24 bits of resolution, it is inevitable that truncation errors will cause harmonics to show up in the test signal, above the quantization noise floor (there is 144dB of dynamic range in 24 bits). And because of the Nyquist theorem, very high-frequency harmonics will be aliased back down.

The important thing to note is that the harmonics/aliasing are very, very low in the original signal (probably inaudible against the analog noise floor of the output stage), but that the aptX decoded output has a much higher aliasing-to-signal ratio.

I honestly don't see new tones brought by aptx. I think some of them were just out of dynamic range for the chart in the source. I seriously concerned how did you made aliasing without frequency change - sample size is a simple arithmetics and it doesn't bring aliasing. At least I don't see how that can happen.

And my problem, I guess is that aliasing is way louder for me. I assume it's amplified by the same clipping effect.

I believe that your results are repeatable. But there could be different explanations and, again, to my knowledge - bit conversion is not bringing aliasing. At the same time I am not sure if it helps to see rev-eng codec result - it just simply not the same code and we don't know if it works exactly the same.

 

[veraideishal]

I honestly don't see new tones brought by aptx. I think some of them were just out of dynamic range for the chart in the source. I seriously concerned how did you made aliasing without frequency change - sample size is a simple arithmetics and it doesn't bring aliasing. At least I don't see how that can happen.

There is a straight line above 10kHz that wasn't there before, and I can assure you that I've already tried to adjust the dynamic ranges of both charts to show all the unwanted components. Again, feel free to repeat my experiment.

As to how bit-depth generates aliasing, here's my (somewhat uneducated) interpretation: If I have a fixed number of bits to quantize my signal to, there is bound to be discontinuities in the sampled waveform. These discontinuities will generate higher harmonics. These higher harmonics can exceed the Nyquist frequency, and that causes aliasing. On the other hand, if I have a much lower bit-depth, the discontinuities are more likely to occur at less predictable points, which causes the harmonics to be spread across a wider frequency range and to overlap each other, hence causing quantization noise.

EDIT: There's also the fact that the Audacity function that generates the chirp has its own round-off errors, which can also cause harmonics to occur, and that the effect of these errors is more pronounced as the bit depth increases (because they are less likely to be truncated).

 

[waynes world]

Thank mate!

I'm planning to use it mainly in the office so the fact that it still works with phonecalls when connected to a laptop will be great for me.

The call quality is pretty good. I tested with the ES100 on the desk about 2.5 feet away from me, and as long as the mic is facing me, my voice sounded fine and was loud enough.

The "ambient mode" might come in quite handy as well at times when you want be able to hear what's going on around you.

Oh yeah, I'm happy about the prospect of balanced output as well (now I finally have a reason to try out my NH's in balanced).

Hmm, I'm alternating between my Sextetts and T50RP's off of the ES100 (in BT mode), and put the ES100 into "3.5 High Performance Mode (2x Current)", and things are sounding really good. That's not supposed to be happening off of a gizmo like this, is it? Lol

I'll pick one up when I go "over there" if it's still in stock on Amazon when it's getting close (I'll be staying in a hotel so I don't want it to arrive there too long before I do, bad experience with things getting lost that way ).

I'll let you know if my enthusiasm for the ES100 "waynes" before you pick yours up, but I doubt that it will!

 

[peter123]

The call quality is pretty good. I tested with the ES100 on the desk about 2.5 feet away from me, and as long as the mic is facing me, my voice sounded fine and was loud enough.

The "ambient mode" might come in quite handy as well at times when you want be able to hear what's going on around you.

Oh yeah, I'm happy about the prospect of balanced output as well (now I finally have a reason to try out my NH's in balanced).

Hmm, I'm alternating between my Sextetts and T50RP's off of the ES100 (in BT mode), and put the ES100 into "3.5 High Performance Mode (2x Current)", and things are sounding really good. That's not supposed to be happening off of a gizmo like this, is it? Lol



I'll let you know if my enthusiasm for the ES100 "waynes" before you pick yours up, but I doubt that it will!

Thanks again! I'll be looking for any further impressions. The balanced output is definitely a nice feature.

One last question: how's battery life in BT mode?

 

[Bubblejuice]

I honestly don't see new tones brought by aptx. I think some of them were just out of dynamic range for the chart in the source. I seriously concerned how did you made aliasing without frequency change - sample size is a simple arithmetics and it doesn't bring aliasing. At least I don't see how that can happen.

And my problem, I guess is that aliasing is way louder for me. I assume it's amplified by the same clipping effect.

I believe that your results are repeatable. But there could be different explanations and, again, to my knowledge - bit conversion is not bringing aliasing. At the same time I am not sure if it helps to see rev-eng codec result - it just simply not the same code and we don't know if it works exactly the same.

Can you explain the problem your having in simple terms? Does it sound bad? It seems other people are no experiencing any problems.

Have you tried RMA? You and the company rep here seem to be going at it, but they are pretty responsive.