[Davy Wentzler]

  Well, at first I used it because it worked with my external DAC while PowerAmp didn't, but since installing ViPER4Android with its own driver that works system-wide I'm finding that every app that outputs sound is now able to access the external DAC, so this is not an advantage for UAPP anymore. But I would like to keep using UAPP though, as the UI has been improving and I hope will continue to improve. Hell, even with the maximum-software-volume problem I can still keep using it, just as long as I keep that volume lowered to some safe value and then just keep the slider permanently off.

 
Some floating point audio files have an amplitude above 0dB (the people who did that need to be expelled to some deserted island, but anyway...) There is a simple test if your audio goes beyond that level: enter the EQ screen, reset all sliders if needed and enable the EQ. If the red led beneath the Gain slider lights, then you know it is clipping, otherwise not.
 
Also make sure you disabled the parametric EQ.

 

[abm0]

   
Some floating point audio files have an amplitude above 0dB (the people who did that need to be expelled to some deserted island, but anyway...)

I'm talking about a 320 kbps MP3 here. I don't think MP3 supports bit depths beyond 16.

 

[Davy Wentzler]

  I'm talking about a 320 kbps MP3 here. I don't think MP3 supports bit depths beyond 16.

 
Please watch the gain led anyway.

 

[m-i-c-k-e-y]

Davy, thanks for giving in for the SACD ISO support.
 
Its always a PITA to convert my ISO rips to .DFF just to let me here them in UAPP.

 

[Davy Wentzler]

  Davy, thanks for giving in for the SACD ISO support.
 
Its always a PITA to convert my ISO rips to .DFF just to let me here them in UAPP.

 
My pleasure. There is only one problem with it and that is that .iso files are usually not recognized by UPnP servers and performance using Network/Samba is usually poor compared to UPnP. I can play them here using Network, but I'm right next to my WiFi router.

 

[abm0]

  Please watch the gain led anyway.

It lights up, but I already expected as much since I loaded up the song in Audacity and saw about 1600 samples hitting 0 dBFS, so I took that to mean it had substantial clipping in it, though somehow no noticeable distortion when played back with certain volume settings in certain players (as I was to find out below).
 
Some more reading yielded further realizations:
 
MP3s don't have bit depth , as the re-allocation of different (smaller!) numbers of bits for each sample is part of the compression algorithm that makes MP3s so small. There's only a bit depth of the original PCM stream from which the MP3 was created, and a bit depth of the reconstructed PCM stream after decoding, but no such thing in the MP3 itself.
 
Armed with this new understanding, I re-open the offending MP3 in Audacity, access the amplification tool, and sure enough I find I would have to adjust the track's gain by -0.528 dB for the highest samples to be reduced to 0 dBFS! Sounds insane, but apparently it's always been part of the normal life of the MP3.
 
So the question becomes: is this an excuse for digital players to produce clipping and distortion at "100%" volume? Considering clipping prevention algorithms have been around for quite a while, I would say no. This is the same idea I see in the technical discussion I found of what bit depth should be used when decoding MP3s:
 
https://hydrogenaud.io/index.php/topic,55336.0.html

Often, 16-bit sources encoded to mp3 remain approximately "self dithering" at the 16-bit level, but this isn't always the case. Sometimes the encoder removes the low level noise, and sometimes it removes high frequency noise shaped dither. This can leave a signal with a noise floor below the 16th bit (i.e. not self dithering). If you don't dither when decoding, then you are effectively truncating a higher bitdepth source, which isn't advisable. If you do dither, then non noise shaped dither could increase the noise floor wrt to the original, and noise shaped dither could increase the peak amplitude, possibly leading to (extra) clipping.

So the best option really is 24-bit decoding. (And, of course, some mechanism of preventing clipping, e.g. ReplayGain clipping prevention). I assume that's what most of us are doing with 24-bit sound cards and foobar2k. There's no reason not to.

 
In UAPP's defense, neither web players like Google Play Music nor desktop players like QMMP have any such clipping prevention implemented and happily produce distortion when turned up to "100%", but OTOH foobar2000 on Android does make this extra effort, to keep the audio output clean even when fed with such "dirty" MP3s. (Plus it has an explicit "prevent clipping" option for its Replay Gain functionality, which may even be calling the same subroutines as its implementation of the "100%" volume setting.)
 
I don't know about others, but when I see this in UAPP's description on the Play store:

This app is a must-have for every HiFi enthusiast, bypassing all audio limits of Android. Without a USB DAC, the app is still one of the highest quality media players around.

... I really expect something as obvious as clipping prevention to be part of the implementation.

 

[m-i-c-k-e-y]

Davy, have problems playing on some iso sacds having multichannel materials. stereo sacd iso plays fine.

 

[Davy Wentzler]

Davy, have problems playing on some iso sacds having multichannel materials. stereo sacd iso plays fine.

 
Yes, I only had one iso file to test which only contained stereo tracks. Please send me an email.

 

[Davy Wentzler]

  It lights up, but I already expected as much since I loaded up the song in Audacity and saw about 1600 samples hitting 0 dBFS, so I took that to mean it had substantial clipping in it, though somehow no noticeable distortion when played back with certain volume settings in certain players (as I was to find out below).
 
Some more reading yielded further realizations:
 
MP3s don't have bit depth , as the re-allocation of different (smaller!) numbers of bits for each sample is part of the compression algorithm that makes MP3s so small. There's only a bit depth of the original PCM stream from which the MP3 was created, and a bit depth of the reconstructed PCM stream after decoding, but no such thing in the MP3 itself.
 
Armed with this new understanding, I re-open the offending MP3 in Audacity, access the amplification tool, and sure enough I find I would have to adjust the track's gain by -0.528 dB for the highest samples to be reduced to 0 dBFS! Sounds insane, but apparently it's always been part of the normal life of the MP3.
 
So the question becomes: is this an excuse for digital players to produce clipping and distortion at "100%" volume? Considering clipping prevention algorithms have been around for quite a while, I would say no. This is the same idea I see in the technical discussion I found of what bit depth should be used when decoding MP3s:
 
 
In UAPP's defense, neither web players like Google Play Music nor desktop players like QMMP have any such clipping prevention implemented and happily produce distortion when turned up to "100%", but OTOH foobar2000 on Android does make this extra effort, to keep the audio output clean even when fed with such "dirty" MP3s. (Plus it has an explicit "prevent clipping" option for its Replay Gain functionality, which may even be calling the same subroutines as its implementation of the "100%" volume setting.)
 
I don't know about others, but when I see this in UAPP's description on the Play store:
... I really expect something as obvious as clipping prevention to be part of the implementation.

 
We use ffmpeg for mp3 decoding. That apparently produces the clipped sound already. And high quality audio and mp3 don't go together well, and chances of finding mp3's that go above 0dB are very rare.

 

[abm0]

  high quality audio and mp3 don't go together well, and chances of finding mp3's that go above 0dB are very rare

They go together well enough to fool all the blind listening comparisons of 320-MP3s vs. lossless formats I've seen reported online. And there are more of these overly-loud MP3s around than you seem to think - I already have about 4 albums from the so-called "Loudness War" period that exhibit problems like this, going into clipping at the slightest misstep in processing/playback. But I understand if you think the value added by fixing this (vs. other things in your backlog) would be too low to bother with - I already know it's easy to fix at my end with the existing volume controls, so whatever.

 

[abm0]

 
...
The EQ and Replay Gain are both off, so it's not from that.
...
 

Yyyeah, no they weren't. The EQ was on and it was causing the distortion, because I hadn't taken the pre-amp control down far enough in that particular preset.
 
I'm a dumb ass.
 
I hereby request that an indicator be added to the main/playback screen, to show if potentially sound quality destroying functionalities like the EQ are on or off.

 

[Davy Wentzler]

  Yyyeah, no they weren't. The EQ was on and it was causing the distortion, because I hadn't taken the pre-amp control down far enough in that particular preset.
 
I'm a dumb ass.
 
I hereby request that an indicator be added to the main/playback screen, to show if potentially sound quality destroying functionalities like the EQ are on or off.

 
You are forgiven.
We will make it even better than that, hopefully next month.

 

[Jazzkammer]

Hi, I searched the thread and couldn't find an answer to the following question:
 
I just bought the HTC 10 so I wouldn't have to carry two devices, and I own the licensed version of UAPP, but when I play hi-res files through UAPP (with "Play Through Android" turned on) it reads that Android is downsampling the music to 48000 hz.   I thought that it was only older versions of Android that, A) downsampled all hi-res to 16bit/48000hz, and B) I thought that especially the hi-res capable HTC 10 would natively play hi-res music.  Why does UAPP say this?
 

 

 

[m-i-c-k-e-y]

"Play through Android" means your using the ASL layer/System driver instead UAPP's driver. 
 
1.Try setting Android Sample Rate to "Variable" 
2.Tick off " Bitperfect "

 

[Davy Wentzler]

  "Play through Android" means your using the ASL layer/System driver instead UAPP's driver. 
 
1.Try setting Android Sample Rate to "Variable" 
2.Tick off " Bitperfect "

 
Note that the bit-perfect setting has no influence when playing through Android.