MPEG-4 audio file not working correctly

[olddesklamp]

When I play this specific audio file, the display bugs out and I can't scroll through the sound file:

I can still skip ahead or back using the buttons next to play/pause. Everything works except for scrolling.

I've tested this with other M4A files and the same thing happens.

[vixalien]

I just tried playing the file, and it works correctly.

does this error happen always?

[olddesklamp]

Sometimes no, sometimes yes. I can't predict if it'll appear normally.

It doesn't seem to be format-specifc either, as I've had this issue with FLAC and MP3 files now. In my tests I've noticed it doesn't seem to happen with OGG or WAV files though.

[vixalien]

it seems to be just GStreamer reporting the duration incorrectly. can you check if the issue happens when you play a file for the first time (i.e. immediately after opening decibels) or play it after playing another file.

[olddesklamp]

It happens regardless of how I open it.

[hellpe]

I'm having a very similar issue with a mp3 file of mine, using the Flathub version of Fedora Silverblue 39. When opened through the app itself, the audio is played but the window gets unresponsive (screenshot below). When opened from Nautilus, the issue only occurs randomly.

[BlobCodes]

This bug now also happened to me.

When this issue appears, the following message is printed on the console:

(com.vixalien.decibels:2): Gjs-WARNING **: 03:13:21.072: Value 18446744073709551615 cannot be safely stored in a JS Number and may be rounded

---

This happens with all my .m4a files, but never consistently.
Here's a video showing it:

Bildschirmaufzeichnung.vom.2023-12-16.03-16-25.webm

---

I'm having a very similar issue with a mp3 file of mine, using the Flathub version of Fedora Silverblue 39. When opened through the app itself, the audio is played but the window gets unresponsive (screenshot below). When opened from Nautilus, the issue only occurs randomly.

Hmm, that's weird. For me, it happens just as often when opening the files through the app.

[vixalien]

Can you check if this hasn't been solved in the recent commits?

[BlobCodes]

It definitely hasn't been fixed (I tried 0.1.7-d386eae).

I have even found an album whose mp3 files always reliably crash the new version of decibels, but not the last stable version from flathub.
..and .m4a files crash just as often as before.

[vixalien]

The issue seems to occur when a file (or different files) is repeatedly opened quickly right?

[BlobCodes]

The issue seems to occur when a file (or different files) is repeatedly opened quickly right?

No, it occurs randomly and seems to have nothing to do with the speed.
Sometimes the app even crashes when opening the file for the first time.

---

Also, I have found out exactly which mp3 files cause the program to crash.

Since a basic MP3 file is just a raw series of audio frames, a program normally wouldn't be able to find out the audio file's length.
Because of this, there are special frames (like LAME INFO tag) that disguise themselves as audio frames, but just contain metadata.

Decibels now seems to have issues with mp3 files not including this metadata because it can't accurately find out the audio length.

You can convert any song to a "stripped" mp3 file via ffmpeg (causing decibels to not respond):

ffmpeg -i input.opus -map 0:a -c:a mp3 -write_xing 0 audio_stripped.mp3

Ref: https://superuser.com/a/1759056

[vixalien]

Thanks, @BlobCodes, for diagnosing this issue. It turns out that GStreamer returns an "undefined" value when it can't get the duration of a track initially. However, that "undefined" value is actually GST_CLOCK_TIME_NONE which has the value of 18446744073709551615.

The issue is that that value is larger than GLib.MAXUINT64 and Number.MAX_SAFE_INTEGER. This caused some hard to debug errors because GJS can't correctly handle BigInts.

The solution is somewhat of a workaround, as we now have a function called get_safe_duration that returns 10 seconds If the parsed duration is larger than what GJS can handle. Because GStreamer will know the actual duration in the future (in a few processing cycles), this is not an issue because the duration will be updated almost immediately. There will also be some errors in the log, but that beats the erroneous crash behaviour.

Please test the changes and let me know if anything has changed by downloading the latest artefact. Thanks!

[sophie-h]

For me it never gets updated to the actual length, see video

Screencast.from.2024-02-23.17-45-46.webm