Poweramp no longer reading embedded album art

[jaxtherogue]

Poweramp 906-910
Android 12 beta 3
Pixel 4

 

Poweramp no longer seems to be able to read the embedded album art in any new opus files I sync to the device. For anything already on the device prior to the last week the album art is fine. No changes were made in how I generate the files (source is all FLAC). Files play with no issues.  Tag editors on my PC (such as mp3tag) are able to see the embedded album art in the files.

[andrewilley]

Try a FULL Rescan in Settings > Library.

Andre

[jaxtherogue]

unfortunately that did not resolve the issue

[John Titor]

16 hours ago, jaxtherogue said:

Android 12 beta 3

"Beta" - Android S is still in beta stage, not stable so it is normal to see bugs here and there. Try with the latest stable version of Android (i.e Android 11), should work fine. Max said he will optimize PA for Android S when it reaches stable stage. It's not worth making something out of the previews/betas because Google changes configuration/APIs everytime they post a new beta update.

Edited August 4, 2021 by John Titor

[andrewilley]

7 hours ago, jaxtherogue said:

unfortunately that did not resolve the issue

Are any of the images particularly excessive in size? The FLAC spec limits embedded images to 24Mb, but it can also depend on how much memory your device provides to apps.

You can long-press on a song title in PA and view 'Info/Tags' to see the size of embedded images. 

Andre

[jaxtherogue]

For the new files the info/tags is showing there is no embedded art at all, though I know there is and have verified as much with a couple tag editing apps on my PC. I use Jriver MC to manage my library and export from flac to Opus for use on my phone.  JRMC also sees the embedded artwork.  I have attached an example file.

01~Lavender.opus

[andrewilley]

Your file doesn't seem to contain very standard metadata, maybe Max could re-code around it? But in the meantime, you could re-save your metadata using a tag editor such as TagScanner or MP3Tag - I tried the former and the resulting file was fine in PA.

By the way, why are you converting to OPUS in the first place? I checked that FLAC track on Bandcamp, and their page says it is CD-quality - which would presumably mean 44.1kHz sampling. But that's not a frequency that OPUS supports, so any such files will get transcoded to 48kHz.

Andre

[MotleyG]

On 8/3/2021 at 7:36 PM, jaxtherogue said:

Tag editors on my PC (such as mp3tag) are able to see the embedded album art in the files.

What format is mp3tag reporting that your files have? Sounds like although mp3tag can read the metadata, it may not be in a format friendly to other media players like Poweramp. Especially Ape tags, these are not well supported.

[andrewilley]

7 minutes ago, MotleyG said:

What format is mp3tag reporting that your files have? 

It's Vorbis at least, but something is a little wonky about it. Simply re-saving it corrects the issue. 

Andre

[jaxtherogue]

2 hours ago, andrewilley said:

Your file doesn't seem to contain very standard metadata, maybe Max could re-code around it? But in the meantime, you could re-save your metadata using a tag editor such as TagScanner or MP3Tag - I tried the former and the resulting file was fine in PA.

By the way, why are you converting to OPUS in the first place? I checked that FLAC track on Bandcamp, and their page says it is CD-quality - which would presumably mean 44.1kHz sampling. But that's not a frequency that OPUS supports, so any such files will get transcoded to 48kHz.

Andre

In what way is the metadata non-standard- I am trying to understand so I can share that info with Jriver in case it is their app that is doing something funky. I doubt I would be able to recognize oddly formated metadata myself.

As for Opus I am converting just to cram more music onto my daily carry phone.  For home listening and on my dedicated portable music player I use flac.

[jaxtherogue]

3 hours ago, MotleyG said:

What format is mp3tag reporting that your files have? Sounds like although mp3tag can read the metadata, it may not be in a format friendly to other media players like Poweramp. Especially Ape tags, these are not well supported.

According to mp3tag it is using "Vorbis Comment".  Just in case I was not clear this only just started happening in the last two weeks. Prior to this PA had no issue with seeing the art in my opus files.  Trouble is, in those last 2 weeks I got updates from jriver, Poweramp, and the Android 12 beta..right now it is looking more like the jriver update might be the source of the issue, although the opus encoder it is using is the same external opus encoder I have always used. But who knows, Jriver MC can get complicated.

Edited August 6, 2021 by jaxtherogue

[andrewilley]

5 hours ago, jaxtherogue said:

In what way is the metadata non-standard-

I don't know, all I can say is that simply re-saving the tag data (making no other changes, sand without changing the actual audio data) using standard tag editing tools fixes the problem. @maxmp might be able to analyse your sample file further to see what is happening here.

I still question the use of the OPUS format for conversion of FLAC music files in the first place, as it is incapable of storing CD-quality recordings without changing them from 44.1kHz sampling to 48kHz, which cannot help the quality. The format is optimised for speech, not music. See https://en.wikipedia.org/wiki/Opus_(audio_format)

Andre

[jaxtherogue]

2 hours ago, andrewilley said:

I don't know, all I can say is that simply re-saving the tag data (making no other changes, sand without changing the actual audio data) using standard tag editing tools fixes the problem. @maxmp might be able to analyse your sample file further to see what is happening here.

I still question the use of the OPUS format for conversion of FLAC music files in the first place, as it is incapable of storing CD-quality recordings without changing them from 44.1kHz sampling to 48kHz, which cannot help the quality. The format is optimised for speech, not music. See https://en.wikipedia.org/wiki/Opus_(audio_format)

Andre

regarding opus. You should give it a listen- and numerous listening tests confirm that Opus is quite excellent for music. A couple posts I can recommend that consolidate a lot of info about opus in this regard, but really you will only know by giving it a try.

Auphonic Blog: Opus, the revolutionary open audio codec for podcasts and internet audio

Results of the public multiformat listening test (July 2014) (coresv.net)

 

[MotleyG]

2 hours ago, jaxtherogue said:

regarding opus. You should give it a listen- and numerous listening tests confirm that Opus is quite excellent for music. A couple posts I can recommend that consolidate a lot of info about opus in this regard, but really you will only know by giving it a try.

Auphonic Blog: Opus, the revolutionary open audio codec for podcasts and internet audio

Results of the public multiformat listening test (July 2014) (coresv.net)

 

These tests were posted in 2011/12, using sample rates of 64k and lower for the A/B testing. I would think that by today’s standards, most people are using much higher rates even for lossy formats like mp3 and AAC. Notably, there were little to no benefits once compression rates exceeded 64k, as evidenced in the results in both links.

if you hear a benefit in your experience, that is clearly your call. But this I would suggest Is subjective at best given these posted actual results. But more importantly, since the format has not gained widespread support from the audio community in the 10 years since it’s inception, it isn’t likely going to get much attention from the player app developers at this time.

[jaxtherogue]

7 hours ago, MotleyG said:

These tests were posted in 2011/12, using sample rates of 64k and lower for the A/B testing. I would think that by today’s standards, most people are using much higher rates even for lossy formats like mp3 and AAC. Notably, there were little to no benefits once compression rates exceeded 64k, as evidenced in the results in both links.

if you hear a benefit in your experience, that is clearly your call. But this I would suggest Is subjective at best given these posted actual results. But more importantly, since the format has not gained widespread support from the audio community in the 10 years since it’s inception, it isn’t likely going to get much attention from the player app developers at this time.

The aduio merits of opus aside- just as a point of interest I have been using opus files with Poweramp for 2+ years and never had an issue until the last 2 weeks.  And Jriver just keeps expanding its opus support. So adoption is slow, but growing in the tools I use the most. All that said, after some more testing I am pretty sure the issue is not with Android Beta or PA, so I am working with the Jriver people to see if something changed in how they are handling opus cover art tags. Thanks for everyone's input!

[jaxtherogue]

After examining a number of files it appears that the "Picture Bits Per Pixel" tag is causing errors with reading the embedded artwork in the file. JRMC is writing to that tag.  MP3Tag strips it out and also strips out the picture dimension tags. and the DBpoweramp converter writes the dimension tags but not the "Picture Bits Per Pixel" tag.  Is it possible that this "Picture Bits Per Pixel" tag is causing an issue for Poweramp?

Here is the EXIF info:

File 1 (embedded art not showing in Poweramp):
Picture Type                    : Front Cover
Picture MIME Type               : image/png
Picture Description             : 
Picture Width                   : 700
Picture Height                  : 700
Picture Bits Per Pixel          : 32
Picture Indexed Colors          : 0
Picture Length                  : 905796
Picture                         : (Binary data 905796 bytes, use -b option to extract)

File 2 (working, tags resaved by mp3tag)
Picture Type                    : Front Cover
Picture MIME Type               : image/png
Picture Description             : 
Picture Width                   : 0
Picture Height                  : 0
Picture Bits Per Pixel          : 0
Picture Indexed Colors          : 0
Picture Length                  : 905796
Picture                         : (Binary data 905796 bytes, use -b option to extract)

File 3 (working, encoded with dbpoweramp)
Picture Type                    : Front Cover
Picture MIME Type               : image/png
Picture Description             : Cover artwork
Picture Width                   : 700
Picture Height                  : 700
Picture Bits Per Pixel          : 0
Picture Indexed Colors          : 0
Picture Length                  : 905796
Picture                         : (Binary data 905796 bytes, use -b option to extract)

Edited September 1, 2021 by jaxtherogue
formatting

[jaxtherogue]

here are the three files mentioned in the previous post. FYI, the JRiver Media Center team is also checking these files.
https://drive.google.com/drive/folders/12n9sSw6RlcgXR0ylhrHhlmM335Mr2tTd?usp=sharing

[jaxtherogue]

Also should have updated that I switched to OGG Vorbis hoping for different results but see the same thing, so this is not an OPUS thing. The above files are OGG.

[jaxtherogue]

Does any of this new info help point to a solution?

[andrewilley]

So you've switched from one obscure format that wasn't really designed for high-quality music in the first place (OPUS) to another obscure format that wasn't really designed for music either (OGG, which is technically a container anyway, was originally more used for streaming and games). Neither of them come anywhere near the top of the most popular file format lists - you don't like to make things easy for yourself do you?

I'll have a quick look at the files you uploaded, but this one is more for @maxmp I suspect.

Andre

[jaxtherogue]

If it helps nearly all of my music is archived in FLAC.  You can listen to transcodes to either ogg vorbis or opus and judge for yourself.  IMO both vorbis and opus beat mp3. I don't have golden ears, but when I listen with iems (JHaudio jh16v2) MP3s fatigue me, opus and ogg vorbis less so.  For car listening I can't say I hear any difference between the formats. If my next phone has more than 128GB of memory, then I'll likely just keep my files in flac.

my weird habits aside, I appreciate you looking into it.

Edited September 3, 2021 by jaxtherogue

[andrewilley]

Results:

1 from jrmc.ogg  <-- PA does not see embedded album art
2 from jrmc.ogg - tags resaved in mp3tag.ogg  <-- 700x700 PNG (~1Mb)
3 encoded with db.ogg  <-- 700x700 PNG (~1Mb)
badtag_Boy from Michigan.ogg  <-- PA does not see embedded album art
goodtag_Boy from Michigan.ogg  <-- 600x600 JPEG

Simply re-saving the two files for which the artwork is not visible in TagScanner (without making any changes) results in the artwork becoming visible in PA, so there is definitely something odd about their metadata embedding. @maxmp will be able to let you know more than I can though, and perhaps code a work-around to allow them to be read?

By the way, that 1Mb PNG image is a bit excessive if you are mainly using the OGG format to save you a few bytes of filesize per the same quality. You are also saving the files at 96kHz, which is also excessive if you are trying to save space (converting to 48kHz would be pretty-much unnoticeable, even with £1,200 ear buds, and would reduce the file sizes a lot).

Andre

 

[jaxtherogue]

3 hours ago, andrewilley said:

By the way, that 1Mb PNG image is a bit excessive if you are mainly using the OGG format to save you a few bytes of filesize per the same quality. You are also saving the files at 96kHz, which is also excessive if you are trying to save space (converting to 48kHz would be pretty-much unnoticeable, even with £1,200 ear buds, and would reduce the file sizes a lot).

All true. It's mostly laziness that the art size is unchanged and the bitrate is that high on my export. JRMC won't auto change the art size for me on conversion (and I want the orginal art in the flac files to be on the high end) and while the ogg encoder can be told to resample, it won't do so dynamically based on the source file. The vast majority of my flacs are 48khz and below so, when the occasional 96+ file slips in, I don't bother to correct it. 

edited to add: after some digging I did find a way for JRMC to downsample to more reasonable 48/44 depending on the source sample rate. It doesn't do it in in the encoder, but I can do it by automatically applying a DSP before it encodes the file. I can the target downsample based on the sample of each source. I am reconverting now to see what the real world difference in the size is for the library i copy to my phone.

Edited September 4, 2021 by jaxtherogue
new info!

[jaxtherogue]

JRiver took a look at all of my example files and found the below"

 

Quote

we save our tags with extra line breaks, which are technically valid but totally useless, and thats really the main difference here. Removing those and the tags start working for me in other tools. This will be fixed in a future build.

So, once the new build if JRMC is out I will test- thought I would share this is case it leads to any adjustment into how Poweramp deals with files with the extra line breaks.

Edited September 7, 2021 by jaxtherogue

[andrewilley]

Max can probably code around this too, and just ignore line breaks in most tags. Some tags need them though - such as comments or lyrics - but they should really only be present when needed.

Andre