22 kHz mono mp3s have wrong duration and seek behavior

[amenders]

Which API doesn't behave as documented, and how does it misbehave? AudioPlayer.duration, AudioPlayer.durationStream: Do not reflect the actual duration of the mp3. In the example 22kHz mono mp3 below, the actual duration of the file is 4:09 (based on play time as well as pulling duration from ffmpeg metadata), but the reported duration is over 18minutes AudioPlayer.seek, AudioPlayer.positionStream: When seeking to a position greater than the current bufferedPosition in a 22kHz mono mp3 (see url below), the position is reported correctly as the duration that was passed to the seek method, but the audio playing is not from that part of the mp3. In the example of the url below, if I seek to Duration(seconds: 120) when that position is greater than the bufferedPosition, the audio plays from roughly the 30s position, even though the positionStream reports an advancing play from 120s on.

Minimal reproduction project The example. Use the following url as a AudioSource.uri or ProgressiveAudioSource: "https://appdata.jesuslifetogether.com/appdatafiles/mp3s/audio/1164_lilies_sparrows_dont_have_energy_leaks/las05t_the_conservation_of_energy.mp3"

To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior: To observe the incorrect duration value:

1. Create the audio source with the supplied URI
2. Pass the source to the player and begin playback
3. Accessing a non-null duration will show a value over 18 minutes.

To observe the incorrect position on seek:

1. Initialize the source and player as above, and then after playing, immediately seek to a position outside of the bufferedPosition (such as 120s).
2. The audio playback will be from roughly the 30s mark in the file, even though the positionStream will continue to be updated with values starting at 120s and incrementing.

Error messages

no error messages

Expected behavior The duration should match the actual play back time of the file, or the time contained in the metadata extracted by ffmpeg, which in this example are the same.

When seeking to a position greater than the current bufferedPosition, the player should start playing the audio correctly from the position requested.

Screenshots N/A

Desktop (please complete the following information):

• OS: N/A
• Browser N/A

Smartphone (please complete the following information):

• Device: Samsung Galaxy A15 5G
• OS: Android 14

Flutter SDK version

[✓] Flutter (Channel stable, 3.19.3, on macOS 14.2.1 23C71 darwin-arm64, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2023.1)
[✓] VS Code (version 1.89.1)
[✓] Connected device (5 available)
[✓] Network resources

Additional context Additional minimal repro link: https://github.com/amenders/just_audio_example

[sethmfuller]

I'm having this same issue. Any help would be greatly appreciated. @ryanheise

[MohammadAssaf10]

I'm having the same issue too. Any help would be greatly appreciated. @ryanheise

[sethmfuller]

@ryanheise, any progress on this? Would be really helpful if this was fixed or if you could provide some direction for me.

[ryanheise]

@sethmfuller Do you have your own MP3 example?

[sethmfuller]

@sethmfuller Do you have your own MP3 example?

Yes! Here is another example, @ryanheise: https://appdata.jesuslifetogether.com/appdatafiles/mp3s/audio/1166_overcoming_the_gravitational_pull/ogp04t_jesus_is_not_your_copilot.mp3

@amenders, and I are working on the same app together. So, that's why the audio urls are from the same api. Both the track @amenders put in his original post and this one are having the same issue with incorrect durations on both of our machines.

[ryanheise]

I suspected as much, which is why I immediately downgraded it on my priority list (I've had people in the past even use fake accounts to post "me too" comments just to artificially make it look like their issue is more in demand than it actually is, to pull my attention away from other issues where legitimately more people are having the issue. That type of usage of GitHub is actually against the GitHub terms of service. In your case, it seems that you pretended to independently have the same issue without disclosing that you are both in fact on the same case, which is a bit dishonest. My last question was just to bring it out in the open. I will now hide all the "me too" comments as they are not constructive.)

@sethmfuller wrote:

I'm having the same issue too. Any help would be greatly appreciated. @ryanheise

[sethmfuller]

I suspected as much, which is why I immediately downgraded it on my priority list (I've had people in the past even use fake accounts to post "me too" comments just to artificially make it look...

@ryanheise - Truly sorry if what I said sounded dishonest. I did not mean for that to be the case. I mostly was trying to support @amenders so that our issue would get to the top of a long list of issues. We’d appreciate it if you could help us. Sorry again.