I recently got a new smartphone which has Android 10.
I use the phone on the car as an audio source via bluetooth.
It happened that when playing some files encoded as lossy.flac, they had important glitches on the left side that makes the files unlistenable.
Once discarded bluetooth and format, I determined that the problem is a defect (or non-compliance) on the android 10 decoder which is triggered by lossywav. A file directly compressed to flac plays fine while if it is previously preprocessed with lossyflac then it fails considerably.
Using the lossywav setting --linkchannels ( which makes it less efficient in reducing the filesize ) reduces this problem a lot, but it can still be triggered in some places.
Has anyone else stumbled upon this problem?
I searched on google for problems with android and flac, and didn't seem to find anything related to this. (There are some problems about not being able to play flac, but that seems to be problems with tags or files themselves).
Of course, using a player that doesn't use the system codecs (like foobar) solves this, but the bluetooth functionality works better with the Samsung Music player.
Try a paid application. You may start with UAPP.
No, I am not looking for alternatives. The alternative has been to regenerate those flacs without the lossywav step.
This thread is more about research and awareness.
Awareness if this is more or less common.
Research as in what does it really trigger this problem and ideally get solved in Android.
I don't have Android 10 or even lossywav files. I seemed to recall something about FLAC encoded lossywav files having a different block size. Woulds this cause the issue?
Are these files compliant with the FLAC subset (https://xiph.org/flac/format.html#subset) specification?
A file directly compressed to flac plays fine while if it is previously preprocessed with lossyflac then it fails considerably.
Has anyone else stumbled upon this problem?
Not directly, but a few years ago I developed a tool similar to LossyWAV, which I call FSLAC (see http://www.ecodis.de/audio.htm#fslac) and which also occasionally has problems with wrongly decoded samples. Specifically, after nulling out LSBs on some clipped audio samples, you get values of 32768 on 16-bit audio, which can be encoded but which are wrapped to -32768 during decoding.
Can you share a short (Lossy)FLAC example of a file on which you get these problems? Maybe it's the same problem as I had with FSLAC.
A clip of the track(s) that, when processed, exhibit the issue would be appreciated - to check whether lossyWAV is the cause.
lossyWAV processed audio in FLAC files plays without issue on my Android 10 phone - I'm using foobar2000 as the player and encode with a 16 to 24 bit sample size increase and a scaling of 0.5 (lossless scaling and 24-bits compresses nearly as well as 16-bits).
Indeed, I should have attached a sample, sorry.
Damn! After an hour trying, I just can't get a snippet to produce the problem!
If I encode the file to flac, I get the problem.
If I cut the file, even naively with a text editor (ok, one like notepad++ which can edit binary data), the problem vanishes!
I'll send a private link to C.R.Helmrich and Nick.C.
I attach the snippet, even though it does not produce the problem, and a snippet of the full track being played by the smartphone
Are you saying that when you cut out only the first 10 seconds or so of the whole song and then play that on Android 10, you don't get the problem? That's strange indeed.
Anyway, the artifacts appear in blocks of length 512 samples, and loading the original snippet into e.g. Adobe Audition doesn't reveal any issues. So it seems this problem is triggered by a bug in the Android decoder and it doesn't seem to be related to the problem I had with FSLAC.
Have you tried playing the unprocessed song reFLACed using -b 512?
Might be good to find a public domain test sample and then post a bug report.
Sorry for the delay.
I don't think that the -b 512 is the problematic part. I also said that, at least for this sample, using the --linkchannels reduced the problem a lot.
I've sent you both the file so you could do other tests, in the case that you actually can reproduce the problem on an android 10.
I might try a few more things during the week, but no guarantees.
public domain: There isn't anything special about these files, other than I created them from some musepack files (SV7) using foobar2000 as the decoder/converter (that's why lossyflac was adequate).
So I might try to get a public domain one and try to reproduce it.
Which lossyWAV settings did you use (other than --linkchannels)?
Do you have any DSP active on your phone audio output?
For the file I sent you both:
* Audio problems:
- lossyWAV.exe %s --stdout|flac.exe - -b 512 -5 -f -o%d --ignore-chunk-sizes
- lossyWAV.exe %s --linkchannels --stdout|flac - -b 512 -5 -f -o%d --ignore-chunk-sizes (I didn't listen with headphones this time so maybe some small annoyances were still present. Also, it might happen that I tried with lossywav 1.3.0c before. Now I am using 1.4.2)
- flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
- flac - -8 -o%d
I also did a couple of tests more:
* Audio problems:
- same as 1st, but when converting, use replaygain only to prevent clipping (this changed the new RG value from -9.78 to -8.06, so almost reducing by 2dB)
- same as 1st, but when converting, use replaygain ( this changed the new RG value from -9.78 to 0.00)
I only tested the --linkchannels option because, if you heard the snippet from playing from the smartphone, the problems only appear on the left channel.
I don't have any equalizing activated, nor system-wide neither on the player.
Changing the phone volume does not affect if it sounds bad or not.
The phone is a Samsung A71. Player is Samsung Music. Android 10 as I said.
Foobar2000 Android plays all the files correctly, just like Audacity on the PC
Oh, and I decided to try with a creative commons file so that I could share it here (if it isn't too big to upload)
It has the same audio problems on the left channel.
It seems that whichever decoder the phone is using doesn't work well with the wasted-bits feature, if channels have different wasted bits, i.e. in the case of lossyWAV processed audio different bits removed.