Poweramp builds 948-957

[GeilerHeinz]

1 hour ago, andrewilley said:

Doesn't happen for me with MusixMatch, so could be something directly related to Genuis. Does it happen with other lyric apps for you?

Andre

The crashes happen with MusicMatch, Genius and also Google on two different devices, Lenovo Tab TB-8705F (Android 10) and Samsung Galaxy A52 5G (Android 13).

Regards 

[maxmp]

@Mandolo5758 the 3rd digit (mm in [MM:SS.mm] should be either 2 or 3 symbols long. Otherwise this is non-standard LRC extension (or, most probably, just a generating software bug).

[maxmp]

@andrewilley would you share those files for tests? For mka files with video track are considered video files.

[andrewilley]

@Mandolo5758 Have a single zero probably ought to be acceptable (although non-standard) but as the format is technically [mm:ss.nn] I guess the single zero might be throwing the timecode recognition syntax. Why not just edit the LRC file in a plain text editor if you only want to add a digit?

Andre

[Mandolo5758]

3 minutes ago, andrewilley said:

@Mandolo5758 Have a single zero ought to be acceptable, but as the format is technically [mm:ss.nn] I guess the single zero might be throwing the timecode recognition syntax. Why not just edit it in a text editor if you only want to add a digit?

Andre

I'll try it

[andrewilley]

28 minutes ago, maxmp said:

@andrewilley would you share those files for tests? For mka files with video track are considered video files.

Will do. The MKA files both scanned in OK a few builds back.

Andre

[maxmp]

@GeilerHeinz thanks for the report - seems to happen for 2 2nd level albums (in Genres/Years).

[maxmp]

@andrewilley when someone codes the "standard" which says timestamp should be [x+:xx.xxx] or [x+:xx.xx], there is no reason to also add [xx:xx.x] (as basically number of possible [ xx . : combinations is infinite here), so at least some files in the wild should follow the "extended format". So such LRC files are welcome - I'll add support for these.

[Airsculpture]

On 2/6/2023 at 5:23 PM, ScarletNeko said:

Thanks a lot for adding support to 32bit FLAC files!

But there is some strange behavior going on. Some files have playback issues. It's almost like a CD skipping, or broken buffering, the audio changes in speed and jitters back and forth.

At first I thought I had broken files, so I went and remade them, with a more recent version of the encoder, but the problem persisted. So I listened to them on the PC and they play perfectly fine there, both the original files and the remade ones, so the files are not the issue. I tried moving the files from the SD card (which is a decent unit with sane speeds) to the internal memory and the problem still persisted. It doesn't seem like weak hardware either as I can play much heavier 32bit WavPack files such as hhx6 ones without issues, and the phone doesn't even warm up or anything. I also tried changing the buffer size, turning the equalizer on or off and changing the output sample rates, no dice, the playback issues continue.

This doesn't affect a single file either, entire albums are like this, while others play fine even if they are made with the exact same settings on the exact same encoder.

Another interesting thing is, there are heavier files (higher sample rates and bitrates) that also play perfectly fine, proving that it doesn't seem like a hardware issue. 32bit 96kHz files seem to be the most affected for some reason.

I gotta say though I'm pretty sure the player I'm using on PC (Foobar2000) to play these files does not use ffmpeg to decode these FLACs instead relying on libFLAC as it has been able to play 32bit FLAC files way before ffmpeg could, so maybe thats an ffmpeg thing?

I’ve had this too on various files, independent of sample and bit rate all of a sudden. Thought it might have been SD card failure but apparently not when same files are played with stock FiiO player on the FiiO M11

[maxmp]

@Airsculpture if you mean 32-bit flac issue, this is fixed in 953.

[ScarletNeko]

1 hour ago, Airsculpture said:

I’ve had this too on various files, independent of sample and bit rate all of a sudden.

This has been fixed on build 953, try again after updating Poweramp and it should be alright now

[Airsculpture]

On 2/11/2023 at 12:27 PM, maxmp said:

@Airsculpture if you mean 32-bit flac issue, this is fixed in 953.

Yep, so far so good 

[maxmp]

Build 954:

• support for more non-standard LRC variations
• minor bugfixes

[Airsculpture]

Nope. Did it again on an ALAC 44khz file.

[maxmp]

@Airsculpture unfortunately, no known issues for ALAC exist, so there were no any changes in this regard.

[andrewilley]

On 2/10/2023 at 11:12 AM, maxmp said:

 would you share those files for tests? For mka files with video track are considered video files.

Thanks Max, the MKA files now scan into the library correctly, and the MPG video file does not.

Andre 

[Ash Roarshock]

I found a few downloaded lrc files that were missing lyrics last week. When I looked at the file in a text viewer they had a single 0 at the end. I changed them to 100 and then they showed up. I noticed a lot of them are like that out there. I think they're coming from musixmatch rips because one had that tag in it.

Edited February 14, 2023 by Ash Roarshock

[andrewilley]

@Ash Roarshock Please could you provide an example of such a LRC file which fails, you can attach it here if you like. Because there is no official spec for lyric files (the whole thing has sort of fallen together over time from a basic idea that one app implemented and others then tweaked and added to) it can be hard to discover all the extra variations that have appeared over time.

Andre

[Airsculpture]

22 hours ago, maxmp said:

@Airsculpture unfortunately, no known issues for ALAC exist, so there were no any changes in this regard.

I don’t think it’s specific to ALAC (it’s just ALAC is all I have) but rather the skip issue highlighted by the other user.

 

Any way, it’s so random (doesn’t happen in the same spot on the same file) and so infrequent, that it’s not a major issue. Plus I can always alternate with the stock FiiO player on the M11.

[maxmp]

@Airsculpture the skip issue highlighted by the user was issue with newly supported 32 bit flacs and this is fixed already.

If you still have issues with some files in build 954 - this is unrelated issue - please share the problematic files with gpmaxmpz@gmail.com for tests.
If it’s random in nature - then it’s not the file issue, but either a CPU throttling (usually can be disabled in app background settings), or buffering issue.

Thanks!

[Airsculpture]

21 minutes ago, maxmp said:

@Airsculpture the skip issue highlighted by the user was issue with newly supported 32 bit flacs and this is fixed already.

If you still have issues with some files in build 954 - this is unrelated issue - please share the problematic files with gpmaxmpz@gmail.com for tests.
If it’s random in nature - then it’s not the file issue, but either a CPU throttling (usually can be disabled in app background settings), or buffering issue.

Thanks!

Thanks mate. Will take a look at that 👍
Found the buffer setting but can’t locate the CPU setting ?

Edited February 14, 2023 by Airsculpture

[ScarletNeko]

On 2/14/2023 at 2:04 PM, Airsculpture said:

I don’t think it’s specific to ALAC (it’s just ALAC is all I have) but rather the skip issue highlighted by the other user.

I used 32bit ALAC in the past, and never had issues with them. I haven't used them recently, it was quite a bit ago, so I can't really assure you that the current version will have no issues, but it shouldn't based on my past experiences.

Try increasing your audio buffer and making sure no other apps are trying to play audio, also close apps that are running to free up some resources, might help. My phone is pretty much archaic already and I have no issues with 32 bit files (never had with WavPack and ALAC, and now FLAC has been working fine as well).

[w3wilkes]

Yesterday I took PA 954 for a drive in my car. I find that 954 still misses song change on occasion and will fall behind displaying the previous songs info on my head unit as I reported in this thread. Just using bluetooth, not android carplay. Running stock android 12 on a Moto Stylus 5G (2022) and playing from the Queue. PA 945 seems to never miss a song change and always displays the correct song info for the currently playing song.

[maxmp]

@w3wilkes when this happens next time, could your please check if notification (on the phone) shows the correct info, and also if the previous track (previously played) is from the same album or has same title. Thanks!

[w3wilkes]

By "notification" do you mean in the PA screen or do you mean android notification? The rest of the question, yes, this time the songs were from the same album and the "now playing" song has a different title than the previous song that is being displayed. When I originally posted the other thread about 948 (linked above) it was from a .M3U playlist in the Queue with all different songs from different albums. And in both the 948 and 954 versions it would out of the blue on a song change it will sometimes catch up and correctly display the "now playing" song. Then after another few songs it would again miss a track change and fall behind on the display. One thing I did try on 954 was to shut off the head unit and turn it back on while it was showing the previous song to what was playing and it then displayed the correct track.