Poweramp shows non-readable tags for some mp3 files with tags in Win-1251 codepage

[VVB]

Hello. 
I see non-readable Album and Artist tags for some mp3 files with tags in Russian Win-1251 codepage. AIMP and Neutron players shows these files normal on the same device.

Device: DAP Fiio M11 plus, Android 10 with Russian system locale, Poweramp build-945-bundle-play, Full version 64bit.
I tried full rescan with Library Scanner setting for non-Unicode tags  as Default and Russian(Win-1251) settings - same non-readable result in both modes.
Please see attached zip file with mp3 file from that album and screenshots of Folder list, Track playing screen and Info/Tags screen for that file.

I tried to re-save the tags in that mp3 file in AIMP player tag editor on PC. The original tags look normal and readable when I opened them in that tag editor. Then I replaced the original mp3 file on the Android device with that new re-saved version and then I run a local Rescan procedure on that folder - in the Folder view I clicked Menu and run Rescan option.  After that Poweramp continued to show those tags in a non-readable way in the lists and on track play screen, but on Info/Tags screen the tags were readable.

When I put the same re-saved mp3 file in a new folder, Poweramp scanned it and tags in that file were displayed correctly. - So there may be a problem with the local rescan procedure as it didn't replaced the tags in the scanned folder.  It would be nice if you can add a correct processing for such files as this original one as these files are displayed correctly in AIMP and Neutron players.

Thank you for the great player!

 

1-orig-mp3-bad-tag-in-Poweramp-and-info-tags.zip

[andrewilley]

Sounds like resaving the file did actually fixed the problem, but a normal background rescan may not detect such a minor tag edit as being a changed file and re-read the tags into the database, so I'd suggest doing a FULL Rescan in Settings>Library after making such changes.

[Edit] Having now looked at the file, the Title tag seems to be formatted with a two-byte UTF identifier (FF FE) at the start of the string, but the Artist, Album and Album Artist tags do not start with any identifier bytes so are interpreted (as would be expected) as a string of plain 8-bit ASCII text. Not much on my PC will read them as you'd want either - I tested the file in TagScanner, MP3Tag., Foobar2000, VLC Media Player, Windows Media Player, and all of them showed "Êàê Æàõíåì!" as the Album title for example, presumably as they all default to reading the bytes using Win-1252 codepage.

Max might be able to do something to code around this issue, but the file is definitely non-standard and Poweramp is interpreting the strings as correctly as it can given the content. I guess your re-saved versions may be re-encoding all the tags into Unicode/UTF-8.

Andre

[VVB]

@andrewilley Thanks for the quick response and your details. I understand the tags in such files might be coded wrong, maybe by some old tag editor. I copied that album from a public share about 2 years ago and had no problems with playing it on PC in AIMP.  

My point is that from the user point of view it would be good to process all such tags according to the system locale or to the Poweramp/ Library/ Scanner/ Non-unicode tags settings  - not as plain 8-bit ASCII text.   In my understanding that setting should set codepage for non-unicode tag strings. So it may be a bug because Poweramp didn't process tags according to the settings?

That's how Neutron player processes tags - they don't have such non-unicode option in settings but with Russian Locale all those tags are readable. With English Locale they are not readable.

Another possible bug is with local rescanning mode. If it named Rescan it should rescan the selected or current folder as deep as in full rescan - otherwise it's confusing.

Thanks for your help!

[andrewilley]

I'm wondering if the issue here is that the tags are mixed encoding? Title and Year (why Year I wonder?!) both have UTF identifiers, whereas Album, Artist, Album Artist and Genre seem to be 8-bit ASCII.

As far as rescanning is concerned, a Full Rescan is quite a lengthy process as it clears all of the existing scanned content and rereads the tags from every single audio file. Even with my mid-sized 7,000 song collection that takes about two minutes. The quick background rescan, which occurs fairly regularly and takes just a few seconds, only looks for apparently changed files since the last full scan and reads the tags from just those files (e.g. new content, deleted files, etc).

I don't know the detailed logic that determines whether an existing file is considered as changed (and thus re-read) or not, but I assume it would be a combination of the file size and the time/date stamp - or possibly whether Android itself has flagged the change. @maxmp could provide more insight into how that decision-making occurs.

Andre

[VVB]

@andrewilley You mean some auto rescanning procedure on file changes etc. I meant an explicit call to rescan from the user - i.e. from local context menu/ Rescan command. And that explicit operation shouldn't differ in deepness from Full Rescan operation from Settings,  but it should be performed within the current scope: selected folders and subfolders - that's my understanding, otherwise it would be confusing from usability point of view. Thanks.

[andrewilley]

@VVB No, the 'Rescan' in general menus is a basic one that should suffice for most cases (such as when files have been added or deleted). It's the same process that occurs automatically on app restarts or file system changes (if you have enabled that option in Settings=>Library=>Scanner). It only takes a few seconds, is non-destructive, and can happen in the background.

The Full Rescan in Settings=>Library is much more of sledgehammer approach, and has a user-warning before commencing. It removes all of the existing entries and then rebuilds the entire music database from scratch by crawling the directory structure and reading all the file tags again. It can take anything from a minute or so to possibly even hours for huge/slow storage collections, can cause glitching in current playback, and possibly there may be some slight loss of old database information (although existing ratings and play counts should be restored after the scan).

So they are two completely different things, and normally a basic Rescan should be all you need. Not sure why your small file modifications are not getting noticed, but as I said before @maxmp could probably elaborate on that.

Andre

[maxmp]

@VVB thanks for the file and details (I already replied to this via 4pda).

This file has proper unicode encoding for title and non-unicode everything else, and this looks the same way e.g. in Windows / Foobar2000.

If possible some workarounds will be added in the next betas.

[VVB]

@maxmp Thanks a lot for your attention! It would be good to have a "deep partial" rescan with local scope on local Rescan command as described above. According to Andrewilley it's not deep as Full Rescan now.  Sometimes I see other minor problems with tags not player related like typos. I usually correct them on PC but when I copy corrected file to my Android device I have to do full rescan to see it corrected. Thank you for the great player!

[maxmp]

@VVB no rescans will help with this file, but I added support for such files in the next build. It will require Full Rescan though. Thanks!