search

vixalien / decibels

Play audio files
https://gitlab.gnome.org/vixalien/decibels
GNU General Public License v3.0
52 stars 17 forks source link

MPEG-4 audio file not working correctly #21

Open olddesklamp opened 11 months ago

olddesklamp commented 11 months ago

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

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 commented 11 months ago

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

does this error happen always?

image

olddesklamp commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

It happens regardless of how I open it.

hellpe commented 9 months ago

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.

Capture d’écran du 2023-12-14 20-11-44-obfuscated

BlobCodes commented 9 months ago

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 commented 8 months ago

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

BlobCodes commented 8 months ago

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 commented 8 months ago

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

BlobCodes commented 8 months ago

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 commented 7 months ago

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 commented 6 months ago

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

Screencast from 2024-02-23 17-45-46.webm