2

I'm working on a Bluetooth speaker system where the same music file results in different SPL up to 10 dBA when played through different devices, such as iPhones and Android smartphones. The system involves passing different decoded audio sources through a same electro-acoustic system, and the outputs are measured using a microphone. I think the only reason is that the decoded audio streams have different levels, but I have no control over the audio processing algorithms, equalization settings, or Bluetooth codecs across devices.

While I've considered Loudness Normalization according to EBU R 128 standard, it seems to sacrifice dynamic range and is computationally inefficient for my target platform.

While achieving real-time loudness normalization is essential, I prioritize computational efficiency over dynamic range preservation due to platform constraints. Are there specific techniques or approaches that can solve my problem?

Edit:

To response sina bala's comment:

To clarify, my rejection of the EBU R 128 standard is not absolute but rather based on concerns regarding computational efficiency and specific requirements of my application.

I have no idea about the details of EBU R 128 for loudness normalization, but the MATLAB example I ran consumed about 10% CPU on my PC. I have reservations about the computational efficiency for this reason. Maybe it doesn't reflect the efficiency of this standard itself, but rather the implementation provided by MATLAB. I haven't yet tested other implementations, such as those in C/C++, which may offer better performance on embedded platforms. Therefore, my concern regarding computational efficiency is based on this initial observation and uncertainty about the efficiency of alternative implementations.

Additionally, my application only requires achieving consistent volume levels across different devices, rather than matching loudness levels precisely. As such, I'm exploring alternatives that may allow me to omit the calculation of loudness, thereby potentially reducing computational overhead.

Ultimately, if the EBU R 128 standard proves to be the most effective solution despite these concerns, I'm open to adopting it.

DSP novice
  • 527
  • 2
  • 10
  • 2
    "it seems to sacrifice dynamic range": isn't that the whole point of normalization? Anyways, you'll have to tell us what metrics for acceptable latency and envelope keeping are, if we're not supposed to blindly guess what you mean if the plenty easy to calculate industry standard is inefficient to you... So far you've not explained why that, again, petty well-suited for embedded platforms real-time part of EBU R 128 doesn't work for you. "I don't feel like it" would have been just as detailed! – sina bala Feb 19 '24 at 03:35
  • @sinabala Thank you for the useful feedback. Please see my edit. – DSP novice Feb 19 '24 at 05:04
  • Does this or this help? – Jdip Feb 19 '24 at 08:07
  • 1
    running Matlab code, which is notoriously slowly interpreted and probably not even meant to be optimized, to determine the performance of an algorithm implemented on an embedded platform makes no sense at all. Your concerns are unfounded. – sina bala Feb 19 '24 at 08:28
  • @Jdip Thank you that does help. Is that to say a simple AGC without loudness calculation also works for most of time? – DSP novice Feb 19 '24 at 10:22
  • Yes, see Hilmar's answer as well. – Jdip Feb 19 '24 at 11:00

2 Answers2

2

A fairly simple way of doing loudness normalization is to run the signal through an A-weighting filter and then simply apply an RMS meter. The tricky part is to set the time constant of the RMS meter. Ideally you want to normalize an entire song with the same level, but the latency would probably be prohibitive.

If you go too fast, you will completely wipe out the dynamics of the song. If you go too slow, the beginning will likely be too loud or too soft until the level has stabilized.

I'm not sure that there is an "acceptable" sweet spot. I don't think this would be acceptable for a commercial product since it modifies the original music too much.

It's also not entirely clear to me why you get this large level difference for, say, the same track played on Spotify. Maybe there is something wrong in the way playback volume is being managed and you can address the root cause of this issues instead of trying to paper over it.

Hilmar
  • 44,604
  • 1
  • 32
  • 63
  • Thank you. I'd like to try that one, A-weighting filter, RMS meter plus a simple AGC. I'm also working on figuring out the reason. I'm using the same music app and playing the same slice of sound track and the device volume is all set to 100%. I've tested multiple devices and they gave all different results - it is hard to test all of them and find the patterns. – DSP novice Feb 19 '24 at 10:42
  • BTW, what is the common way for a commercial product to solve the problem? Is it EBU R 128? – DSP novice Feb 19 '24 at 10:46
0

It is not clear to me if you «own» the playback chain or not. Is the problem that some songs are mastered/streamed louder than others? If so, ReplayGain (or possibly propietary rip-offs) would seem to be the solution, as that attaches a single scalar «loudness» estimate per song/per album that is pre calculated offline (ie with full lookahead).

If the problem is that some devices applied dynamic processing that makes them louder than others depending on material, I have no idea how to solve that.

Knut Inge
  • 3,384
  • 1
  • 8
  • 13
  • Thank you. I don't own the whole playback chain, but a part of it, which starts from the decoded audio stream and ends before the signal being sent to the DAC. My input is a block of stereo audio stream and other information I have is something like bit depth, sample rate and block size, nothing about the metadata including the track name, artist, album or loudness. Unfortunately I think the problem is the latter you mentioned. – DSP novice Feb 20 '24 at 02:09