USDX Song does not end after #MP3 ends

Actual behaviour

For some songs, after the song is over, the time starts counting into negative values (when time is counting downwards), never showing the score screen.

Expected behaviour

The song should end when the audio track is at the end and show the song screen, as is the case for most files.

Steps to reproduce

Not sure if that is the reason, but for the song I used to create the above screenshot, the audio track from the video file (mp4) is reused, so #MP3:video.mp4. Maybe that is the reason that the song end is not detected?

EDIT: Indeed, after extracting the audio track to an mp3 and setting #MP3:audio.mp3, the song’s end is detected properly. So I assume there is a bug when reusing the video’s audio track.

Details

Provide some additional information:

USDX version: latest master
Operating System + version: macOS Monterey (12.1)

Feb 06 '22 20:02 bohning

is the audio track shorter than the video track of the mp4 file? Does it use CBR or VBR audio encoding?

Feb 06 '22 22:02 basisbit

No, they should have the exact same length (it is one mp4 that contains a video and an audio track). The audio track is MPEG4 AAC (mp4a), I don’t know exactly how to determine if that uses (or even offers) VBR?

Feb 06 '22 22:02 bohning

I always use separate audio files, and I also have this happening. Not often enough to be a dealbreaker, but it's absolutely a thing.

My findings so far over the past few years:

it seems to happen more often on lower framerates
it seems to happen more often on lower-spec CPU's (lower clockspeeds?)
it seems to happen more often with VBR songs compared to CBR songs, but I've seen it happen with CBR as well
I've seen it happen with songs that didn't even have any video (this is extremely rare though)
I have seen the same song exhibit both the actual and the expected behaviour on the same hardware when playing through the song multiple times
possibly (I don't have any hard data on this) it gets triggered easier if there's more microphone inputs/players

Even on the worst performer (a low-speed dual-core i3 with a 30fps beamer), this happened maybe on 1 out of 10 songs, probably less.

This is on USDX latest master on Archlinux.

I have never been able to consistently figure out a way to trigger it though. If usingvideo.mp4 for both #VIDEO and #MP3 triggers it 100% of the time, I'm probably hitting a different bug (if so I'll move to a different ticket) but I'm unable to do any testing in the coming days.

Apr 29 '22 17:04 barbeque-squared

Never have seen this behaviour on Windows when using a somewhat current usdx version, and I have seen many thousands of songs been sung. Thus, I'd assume this might be caused by some buffer overflow in the code for audio playback which is not the one used on Windows, or some problem with some ffmpeg handling playback code.

Apr 29 '22 18:04 basisbit

Oh and @barbeque-squared if you only saw those issues in MLK, then blame it having distributed a quite old version until a recent update.

Apr 29 '22 18:04 basisbit

@basisbit

This is on USDX latest master on Archlinux.

Apr 29 '22 18:04 barbeque-squared

Could you maybe retry with older ffmpeg versions, to figure out if it possibly is an issue with code related to that?

Apr 29 '22 18:04 basisbit

I also see this behavior, I haven’t really figured when and where it happens (I am on Mac)

Apr 29 '22 19:04 bohning

I can reproduce this issue on multiple machines using our version of ABBA - Dancing Queen. The audio file is few hundred milliseconds longer than the video, and if I cut some milliseconds off the audio file the issue goes away. OS is Ubuntu 22.04 on both machines.

Am I allowed to post that song here for testing purposes?