[PiSkyHiFi]

I can't test Apt-x HD. It's possible that it's superior to AAC. Aptx is sub-band ADPCM low complexity codec that basically cuts bits based on a frequency. Unfortunately, that leads to clearly audible high-frequency noise and in ES100 case it sometimes leads to amplification of aptx harmonics and brings sand noise. I'm completely confident that I do not hear 24vs16 bit difference at all (as well as above 44.1 sample rate). In fact, I don't believe anyone can pass blind test of properly dithered 16bit 44.1 vs anything above. But aptx is not even true 16 bit, so aptx-hd maybe solves that issue. But I don't have sources for it - there is no aptx-hd in S8 or Windows or OSX. And there are no USB BT that has it. And Radsone decided to save cost of LDAC certification (which is fine) which I at least can use in Android 8.

At the same time, AAC is vastly superior codec to aptx for music and it works on most sources now. Yes, it has a latency issue, which I couldn't care less for music. Plus it cuts >18kHz sound (I don't hear anything there doesn't matter volume). Plus it generates a lot of harmonics which human ear can't hear anyway at such bitrate. Maybe it drains a battery somewhat faster. While aptx generates stupid noise that anyone can hear and somebody might even like that since it bumps high frequencies up.

Somehow there are no real test studies published on Aptx HD (Qualcomm signs hush agreement with partners?), but I would assume AAC could still be superior just because it's smarter and I have a feeling that large bandwidth of Aptx-HD only used for high sample rate and not for preserving even first 16 bits. Anyway, it's just my speculations and I could be wrong.

I still insist something is wrong with the implementation of aptx in ES100 (or with combination with my sources), but it's easily could be a fault of CSR itself, I don't know - need more tests and therefore more time.
But AAC with sharp filter is good enough for me. And in such form, I like this device a lot - if only AAC can be fixed.

I can drive HD650 in balanced mode, but I wouldn't say it's loud enough for going outside. 600Ohm, I guess should be not enough volume even for home use.

Jitter Cleaner is a complete gimmick by CSR, IMHO - AKM is jitter resistant already and whatever happens there is so much below rest of noise that I wouldn't bother - if it works, fine, if not - turn it off and don't look back.

P.S. I'm reading DCT patent details https://patents.google.com/patent/US20130216059A1/en + http://radsone.com/radsone-home/doc/Radsone DCT.pdf and it sounds like some spatial reverberation technology to make slight room effect + clarity filter afterwards. It could potentially improve psychoacoustic data restore like AAC. So since there are many tests made by Radsone - @wslee, that would be great to hear about results in laynman terms. Since LG, Astell&Kern and Audio Technica decided to license this from Radsone - there should be clear benefits.

I agree that AAC is the best codec at the same bitrate, it is also the most expensive computationally, which is no surprise.

I also agree that well mastered 16 bit 44.1 can't really be improved upon for nearly all human ears - they won't distinguish it from anything better, mine included, but you also need a decent analog stage of course.

I believe the jitter cleaner is just the method they used to resolve the clock differences between source and sink. When using USB isosynchronous mode, buffer over-run and/or under-run are bound to occur in this configuration, causing audio resync which will be audible. The better solution is to use asynchronous mode, where the sink has the only clock and it controls the flow of information maintaining the buffer without any need for resync. It needs more circuitry though and so adds to cost.

I get the impression the cleaner is a sensible no-audible resync using DSP, I don't know for certain though, that's my interpretation of what WSLee said in this thread. It's a good method for the limited hardware.

I've witnessed cheap Bluetooth adapters actually slowing down the music and speeding it up to maintain a consistent buffer.... kind of shooting itself in the foot really, so glad I can avoid that stupid thing now.

All of this will be moot in a few years.... eventually Bluetooth will be able to transmit standard uncompressed audio, so all these patents and attempts to resolve complicated compression issues will disappear.

 

[HiFlight]

• I have attempted to download the v.1.14 firmware update but always get redirected to www.wix.com which appears to be a web hosting site. I used the link provided by Radsone as the source for the download. Anybody else experiencing this issue?

 

[PiSkyHiFi]

• I have attempted to download the v.1.14 firmware update but always get redirected to www.wix.com which appears to be a web hosting site. I used the link provided by Radsone as the source for the download. Anybody else experiencing this issue?

I can't access https://www.ear-studio.com/ at present - connection refused.

Hopefully just a hosting issue.

 

[PiSkyHiFi]

I agree that AAC is the best codec at the same bitrate, it is also the most expensive computationally, which is no surprise.

I also agree that well mastered 16 bit 44.1 can't really be improved upon for nearly all human ears - they won't distinguish it from anything better, mine included, but you also need a decent analog stage of course.

I believe the jitter cleaner is just the method they used to resolve the clock differences between source and sink. When using USB isosynchronous mode, buffer over-run and/or under-run are bound to occur in this configuration, causing audio resync which will be audible. The better solution is to use asynchronous mode, where the sink has the only clock and it controls the flow of information maintaining the buffer without any need for resync. It needs more circuitry though and so adds to cost.

I get the impression the cleaner is a sensible no-audible resync using DSP, I don't know for certain though, that's my interpretation of what WSLee said in this thread. It's a good method for the limited hardware.

I've witnessed cheap Bluetooth adapters actually slowing down the music and speeding it up to maintain a consistent buffer.... kind of shooting itself in the foot really, so glad I can avoid that stupid thing now.

All of this will be moot in a few years.... eventually Bluetooth will be able to transmit standard uncompressed audio, so all these patents and attempts to resolve complicated compression issues will disappear.

I'm getting my USB and Bluetooth protocols mixed a bit here I think - honestly, I don't know how Bluetooth resolves clock issues in general, I only know the USB methods.

 

[waynes world]

But, I can hear hi-pitch noise in all apt-x devices now,

Aptx is sub-band ADPCM low complexity codec that basically cuts bits based on a frequency. Unfortunately, that leads to clearly audible high-frequency noise and in ES100 case it sometimes leads to amplification of aptx harmonics and brings sand noise.

I still insist something is wrong with the implementation of aptx in ES100 (or with combination with my sources), but it's easily could be a fault of CSR itself, I don't know - need more tests and therefore more time.

I guess I'm lucky that I don't have bat ears and I don't pick up on the hi-pitch, hi-frequency or sand noise, on the ES100 or on any of my other BT devices - all APTX (well, I very occasionally and very temporarily do, but for 99.9% of my listening time I don't).

I'd like to test AAC or APTXHD to find out if I can hear any difference, but my S7 only supports APTX.

Anyway, like I said, I'm lucky I guess. We almost should start a poll to see how many people do and do not notice this.

 

[SubMash]

I'm getting my USB and Bluetooth protocols mixed a bit here I think - honestly, I don't know how Bluetooth resolves clock issues in general, I only know the USB methods.

Well, I just realized that CSR is not the one that does jitter cleaning. And it couldn't be, since it doesn't have any sync source.
It's a DAC. It uses own clock instead of CSR and if their clocks mismatch too much - no luck.
Or if source clock mismatch - buffer would end up eventually.

I guess I'm lucky that I don't have bat ears and I don't pick up on the hi-pitch, hi-frequency or sand noise, on the ES100 or on any of my other BT devices - all APTX (well, I very occasionally and very temporarily do, but for 99.9% of my listening time I don't). I'd like to test AAC or APTXHD to find out if I can hear any difference, but my S7 only supports APTX.
Anyway, like I said, I'm lucky I guess. We almost should start a poll to see how many people do and do not notice this.

You should get Oreo next month. But not HD.
I don't hear high frequencies, but they make sandy noise at 8-11kHz and if things overloaded enough - you can hear it. Mosquito test is dead silent in AAC for me, but I can see it makes output signal on the recording. On APTX with enough volume, you can hear those frequencies swinging up-down and sand noise around it.

P.S. Btw - BT5 fits uncompressed PCM already and I bet it's more energy efficient than any of those codecs.
P.P.S. https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ - it just barely fits in ideal conditions 1% overhead which won't work, obviously. So some real lossless compression would be necessary - like FLAC.

 

[antdroid]

I guess I'm lucky that I don't have bat ears and I don't pick up on the hi-pitch, hi-frequency or sand noise, on the ES100 or on any of my other BT devices - all APTX (well, I very occasionally and very temporarily do, but for 99.9% of my listening time I don't).

I'd like to test AAC or APTXHD to find out if I can hear any difference, but my S7 only supports APTX.

Anyway, like I said, I'm lucky I guess. We almost should start a poll to see how many people do and do not notice this.

From what I've gathered, this seems to only affect highly sensitive IEMs. My iSine 10 and MD+ dont seem to fall into this category, so that could also be why you, like myself, don't hear it.

 

[waynes world]

Well, I just realized that CSR is not the one that does jitter cleaning. And it couldn't be, since it doesn't have any sync source.
It's a DAC. It uses own clock instead of CSR and if their clocks mismatch too much - no luck.
Or if source clock mismatch - buffer would end up eventually.


You should get Oreo next month. But not HD.
I don't hear high frequencies, but they make sandy noise at 8-11kHz and if things overloaded enough - you can hear it. Mosquito test is dead silent in AAC for me, but I can see it makes output signal on the recording. On APTX with enough volume, you can hear those frequencies swinging up-down and sand noise around it.

P.S. Btw - BT5 fits uncompressed PCM already and I bet it's more energy efficient than any of those codecs.

Will Oreo do anything for me bluetooth-wise? (I took a quick look, but I couldn't find anything)

And regarding BT5, I won't be able to make use of that on my S7, will I?

Thanks.

p.s.
I am happy about this one: "Android Oreo offers the option to have Wi-Fi turn back on when you're near a known, safe Wi-Fi network, such as your home."
And ecstatic about this one LOL: "With the release of Android Oreo 8.1, Google "fixed" the hamburger emoji by putting the cheese on top of the meat. "

From what I've gathered, this seems to only affect highly sensitive IEMs. My iSine 10 and MD+ dont seem to fall into this category, so that could also be why you, like myself, don't hear it.

Great point (I forgot about that).

 

[SubMash]

Will Oreo do anything for me bluetooth-wise? (I took a quick look, but I couldn't find anything)

And regarding BT5, I won't be able to make use of that on my S7, will I?

Thanks.

You should be able to change to AAC, LDAC without hacking it. But as you can see - it doesn't stick to it after reconnection.
S7 has no BT5. But I don't even know if S8 has 2M PHY LE and even so - ES100 doesn't have it.
And even then - there are no Androids that have such codec and won't have for quite some time.
It's easy to do a custom virtual sound card for Mac/PC, but not for the phones.

 

[waynes world]

You should be able to change to AAC, LDAC without hacking it. But as you can see - it doesn't stick to it after reconnection.
S7 has no BT5. But I don't even know if S8 has 2M PHY LE and even so - ES100 doesn't have it.
And even then - there are no Androids that have such codec and won't have for quite some time.
It's easy to do a custom virtual sound card for Mac/PC, but not for the phones.

I didn't realize that the S7 could be hacked to use ACC or LDAC. But I don't hack my phone, so that will be cool if I can use ACC or LDAC with my S7/Oreo. Thanks! Maybe now I will also be bugging WS for an option of sticking with or forcing a particular codec lol.

 

[SubMash]

Read a bit more about Aptx-HD https://android-review.googlesource.../+/318907/1/stack/a2dp/a2dp_vendor_aptx_hd.cc
So it's exactly same as Aptx with only 1 difference - it's +2 bit per each 5.5kHz subband.
10,6,4,4 bits per band instead of 8,4,2,2 at 4 times lower frequency than samples.

Technically >11kHz gets +100% resolution, 5.5-11kHz +50% and <5.5kHz +25%.
I assume noise at the top should significantly decrease.

Aptx was 350`800 bps, HD is 529`200. Output format only 24bit.

LDAC is the same principle, but it has 4 layers of filters instead of 2 and so 16 subbands - that should make significantly lower crossover noise spikes.

I have absolutely no idea why Samsung so evil (protects own UHQ codec that nobody needs?) by blocking free aptx-hd.
It's there and they just blocked it.

 

[antdroid]

I didn't realize that the S7 could be hacked to use ACC or LDAC. But I don't hack my phone, so that will be cool if I can use ACC or LDAC with my S7/Oreo. Thanks! Maybe now I will also be bugging WS for an option of sticking with or forcing a particular codec lol.

Android Oreo will have AptX among other CODECs built into android. It still requires the phone manufacture to license the use of it though. But if you use things like Magisk, you can enable it if your mfg does not. This can be done without Oreo as well.

Read a bit more about Aptx-HD https://android-review.googlesource.com/c/platform/system/bt/+/318907/1/stack/a2dp/a2dp_vendor_aptx_hd.cc
So it's exactly same as Aptx with only 1 difference - it's +2 bit per each 5.5kHz subband.
10,6,4,4 bits per band instead of 8,4,2,2 at 4 times lower frequency than samples.

Technically >11kHz gets +100% resolution, 5.5-11kHz +50% and <5.5kHz +25%.
I assume noise at the top should significantly decrease.

Aptx was 350`800 bps, HD is 529`200. Output format only 24bit.

LDAC is the same principle, but it has 4 layers of filters instead of 2 and so 16 subbands - that should make significantly lower crossover noise spikes.

I have absolutely no idea why Samsung so evil (protects own UHQ codec that nobody needs?) by blocking free aptx-hd.
It's there and they just blocked it.

I believe the manufacturer (samsung) still has to obtain license to use Apt-X HD, if I recall correctly. My phone manufacturer, Essential, couldnt put AptX/HD into their Oreo betas becaue of licensing issues, but finally released it in Oreo 8.1. You could enable it via root or via magisk systemless root though.

 

[Bubblejuice]

Connect by BT to recognize, but don't send music over it by turning it off in BT device settings.

So bluetooth has to be on even when the device is connected through a cable to be recognized? Well that sucks. :/

 

[SubMash]

So bluetooth has to be on even when the device is connected through a cable to be recognized? Well that sucks. :/

When you need to use app, yes. When you don't use it - no.

 

[rkw]

And regarding BT5, I won't be able to make use of that on my S7, will I?

Doesn't matter, because BT5 offers no advantages for audio. It was discussed here:
https://www.head-fi.org/threads/radsone-earstudio.867366/page-10#post-14021985