[bigshot]

I haven't thrown away the originals. The CDs are in boxes on steel shelving in my garage. I can compare them any time I want. But there isn't any point because I already did extensive controlled comparison tests and I determined that AAC 256 VBR is audibly transparent (which to me means no audible difference between lossless and lossy)... Earlier in the thread you conceded that high data rate AAC was indistinguishable from lossless, and I asked you what audible benefit there was in lossless... and you went back to tangents about definitions of words and abstract theories about numbers that were unrelated to audibility. That is what keeps sending us in circles. You never address my question. What is the audible benefit of lossless when lossy sounds exactly the same?

 

[SomeGuyDude]

I had hopes tor this one. Sometimes people stumble in here with potential. I might have been able to learn something from him about codecs I'm not familiar with like Aptx. But with no interest in backing what he says up, and falling back on semantic arguments and deflection to validate his opinions, I don't see much hope. I redefined my wording to eliminate the word transparent that he wasn't able to understand, and he slipped back to "we can never know". If I provide evidence that we actually can know, he slips back to semantics. The clue has been given. You can lead a horse to water...

TBH what I'm more interested in is the transition from one compression codec to another BT transfer codec, i.e. OGG -> aptX vs mp3 -> AAC vs AAC -> aptX vs AAC -> AAC

I don't give a crap about compression beyond that, I'm just wondering how they all do via those transfers.

 

[mhoopes]

I think you are confusing two different things - the source bitrate (and codec) and Bluetooth A2DP bitrate+codec.

All bluetooth devices I've seen used AAC VBR @ 256kbit (forcing CBR causes failure), and I've never seen them exceed 256kbit (but I've seen them transferring less).
I wasn't able to find any definiitive specs on this, so it's possible that >256kbit can be supported, or that some devices support CBR.

In any case, whatever source you use will first be decoded and sinked internally to PCM first, then transmitted using a codec. It might depend on the smartness of the source device how this is handled, i.e. what bitrates shows as supported on the bluetooth audio device and can be used (I'd be very surprised if it was anything else than 44.1kHz/32 bit float in case of A2DP).
aptX might claim some marketing mumbo jumbo about 48kHz/24, but that's likely just the sampling rate coming out of the bluetooth chip in the receiver, or some "marketing equivalent quality" they paired with it, but in reality it will always come as a 44kHz/32b source and nothing else.
Theoretically it should be possible to simply forward the AAC codec samples from the source (like Apple Music), but I don't think it's possible in practice due to the 256kbit limit, so you always end up resampling it. And what would the system do about mixing sounds together? One might be AAC music the other might be a ringtome stored as mp3, do you suddenly start encoding both to AAC and forwarding it? No, you mix it into the PCM stream...
Whether that is transparent or not - I don't think you'd know the difference anyway.

I'm jumping in a little late...but I'm on the iOS platform, and am preparing for my post-iPhone 6s Bluetooth future. As such, codec handling becomes the major quality bottleneck.

I was also curious about audio mixing in iOS. When listening to music with the Music app, alerts are audible, but the music is smoothly muted when the alert is played. I've found that most system sounds (keyboard clicks and the lock sound, specifically - and I verified they're enabled) are suppressed entirely if the ringer switch is set to "off".

I took a look at the "Accessory Design Guidelines for Apple Devices" document [link]. Here's what they have to say on pp. 56-57 about the differentiation of system sounds and music:

"9.12.2.1 Differentiating Audio Content from System Sounds
Music-like content can be differentiated from system sound by adding support for Audio/Video Remote Control Profile (AVRCP) version 1.3 or later. The AVRCP profile allows an accessory to be aware of the audio playback state in the Apple device, using notifications. See Audio/Video Remote Control Profile (AVRCP) (page 53).

9.12.2.2 Expected Audio Routing Behavior for A2DP
The accessory should tune its audio routing behavior based on audio content over the A2DP channel. If audio data contains music, then it is expected that the accessory speakers are dedicated to audio data coming via the Bluetooth link and any other audio playback is paused. If audio data contains system sound, then it is expected that the accessory can render audio as desired. If the accessory is playing audio from a different source, then system sound data can be mixed with the existing track for playback; it is not necessary to pause existing audio playback on the device."

Music-only scenario:
When the phone and receiver volume levels are not synchronized, it's recommended that the phone volume be set to 100% to maintain the maximum dynamic range. I've heard that when the volumes are synchronized (meaning there is a single volume adjustment that can be made on either transmitter or receiver), the Bluetooth stream is transmitted at 100% volume.
I don't know what kind of transcoding iOS is doing in non-synchronized volume control mode. They're not necessarily mixing other sounds in, but if not, is there still a final MPEG-4 AAC conversion involved there, and is it happening even at 100% phone volume?

It's not clear to me in the Guidelines document, and a preceding figure on p. 57 mentions "mixed in A2DP audio playback" on the Device (phone) side:

 

[shortwavelistener]

TBH what I'm more interested in is the transition from one compression codec to another BT transfer codec, i.e. OGG -> aptX vs mp3 -> AAC vs AAC -> aptX vs AAC -> AAC

I don't give a **** about compression beyond that, I'm just wondering how they all do via those transfers.

I'm also curious about these as well.

 

[Vin60]

We just had overwhelming discussion about this subject on some Russian forum and it was really a battle - all the android users insisted aac over bluetooth is irrelevant, why I, as iphone user, insisted I do not hear any difference between AAC from apple music and .flac over USB external DAC. Finally we made an audio record through computer audio input to see the spectrogram. Source was Iphone bluetooth transmission to external DACs FIIO BTR3 and then to BTI-031 as well as Huaiwei P20 PRO plus AiAiAi TMA-2 with detachable cable to check AptX formats and LDAC.
It appears that 256k AAC file, which has full frequency coverage up to 22Khz is transmitted by iphone over bluetooth with frequency cap at 19Khz (which corresponds to 192 kbit/s mp3), while android phone cap it at 14Khz (which is worse then 128 kbit/s mp3), and aptX preserved the full bandwidth..
This is very unfortunate as it means you can not have even 256 kbps AAC over bluetooth with Apple products, and you need to get high quality expensive external DAC to have proper sound over USB. Aptx codecs should be definite preference for Android users and they should avoid AAC transmission by any means. Also its easier and cheaper for Android users to get proper sound from their devices.

 

[bigshot]

Is it capping the frequencies, or is it actually downsampling? The difference I hear between AAC192 and 256 isn't the frequency range, it's a difference in the level of artifacting.

 

[Vin60]

Is it capping the frequencies, or is it actually downsampling? The difference I hear between AAC192 and 256 isn't the frequency range, it's a difference in the level of artifacting.

I vote for downsampling - I think iphone decodes original ACC, adds volume info + system sounds and then encodes it, but with lower bitrate. This is only assumption though..

 

[bigshot]

Interesting. I guess I usually use AirPlay and that would play AAC 256 as AAC 256.

 

[Vin60]

Interesting. I guess I usually use AirPlay and that would play AAC 256 as AAC 256.

Indeed, because it does not play but just send over wifi to be decoded and played on other device. Technically Bluetooth does the same, but due to much lower bandwidth it uses dedicated codecs for transmission

 

[bigshot]

Maybe the bluetooth format is nearing its sunset. Either that or people just don't care or think it makes enough of a difference. In 99% of the music I play, the difference between AAC192 and AAC256 wouldn't be audible. In fact, I've only found one album where I can actually hear the difference.

 

[Vin60]

Maybe the bluetooth format is nearing its sunset. Either that or people just don't care or think it makes enough of a difference. In 99% of the music I play, the difference between AAC192 and AAC256 wouldn't be audible. In fact, I've only found one album where I can actually hear the difference.

Its obviously at its dawn, keeping in mind aptxHD, aptxLL and LDAC, which is more then enough to send any existing sound quality file over bluetooth. Only apple is screwed so far.
Please note 192 kbps mp3 is not the same as 192 kbps AAC and if your headphones are good enough you can easily hear the difference between file capped at 22khz and file capped at 19 Khz

 

[Monstieur]

I vote for downsampling - I think iphone decodes original ACC, adds volume info + system sounds and then encodes it, but with lower bitrate. This is only assumption though..

I've tested multiple receivers and found that macOS uses AAC at 320 kb/s if aptX is disabled. Can you confirm whether the downsampling of the music stream occurs on macOS as well? Both iOS and macOS resample to 44.1 kHz 16-bit before AAC encoding.

The 22.05 kHz bandwidth is not meant to be used fully in the first place. There is a buffer of 2 (or 3?) kHz in most analog and digital workflows to allow for aliasing and gradual filter slopes, which would explain only upto 19 kHz being transmitted.

If no filters are being applied, the full 22.05 kHz signal could be transmitted, but the system resamples all audio streams and if some of them are at 48+ kHz sample rates or higher bit depths, it would need to resample while respecting the buffer. Even the act of mixing the music stream with silent system audio would probably necessitate the buffer.

 

[Vin60]

I've tested multiple receivers and found that macOS uses AAC at 320 kb/s if aptX is disabled. Can you confirm whether the downsampling of the music stream occurs on macOS as well? Both iOS and macOS resample to 44.1 kHz 16-bit before AAC encoding.

All the Apple Music files are AAC 256 kb/s, so frankly speaking, I have no clues, why Mac Os would upsample them? Indeed they resample to 44,1 before encoding, but then result of this new encoding transmitted over bluetooth has cap at 19Khz. Theoretically its possible this is external dac problem, however the very same DACs provide full bandwidth for aptX signal, so I doubt this is the case.

 

[Jaywalk3r]

… if your headphones are good enough you can easily hear the difference between file capped at 22khz and file capped at 19 Khz

More importantly, one's ears need to be sensitive enough. Most adults can't hear 19KHz, and few humans at all can hear over 20KHz. (The difference between those frequencies, in terms of notes, is tiny.) None of it would be "easily heard".

 

[Monstieur]

All the Apple Music files are AAC 256 kb/s, so frankly speaking, I have no clues, why Mac Os would upsample them? Indeed they resample to 44,1 before encoding, but then result of this new encoding transmitted over bluetooth has cap at 19Khz. Theoretically its possible this is external dac problem, however the very same DACs provide full bandwidth for aptX signal, so I doubt this is the case.

Increasing the bit rate is not upsampling... It just reduces the chance of recompression artifacts.
I edited my previous post explaining the 19 kHz limit.