Rockbox

Tasklist

FS#13133 - Opus files with embedded artwork 45.8KiB or larger skip near beginning

Attached to Project: Rockbox
Opened by Eli Bildirici (bilditup1) - Sunday, 29 October 2017, 06:10 GMT
Task Type Bugs
Category Music playback
Status Unconfirmed
Assigned To No-one
Operating System Sansa Clip Zip
Severity High
Priority Normal
Reported Version Release 3.14
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Opus files that contain album artwork ~45.8KiB or larger skip near the beginning.
This issue has been observed using the latest stable 3.14 build for the Sansa Clip Zip, as well as on xvortex's fork for the XDuoo X3. This happens with files encoded both with and without the --vbr flag, on Opus versions going back to opustools 0.1.5/libopus 1.0.1 through the current 0.1.10/1.2.1, with files of arbitrary bitrate, size, or length.
How much skipping occurs appears to relate to bitrate - the lower the bitrate, the greater the skip. This manifests itself as follows: the first second, 00:00-00:01, plays back fine. Then, playback skips to 00:04, for files of middling bitrate (128-180 kbps or so. On lower bitrate files, the first second is skipped, then 00:01-00:02 is played back, and then we skip forward again to 00:05 or 00:06.
The files playback fine in foobar2000 on Windows and Android, as well as GoneMAD on Android. One stripped of artwork, or replaced with artwork of the correct size, the files playback fine on Rockbox, too.
At first I thought this behavior was limited to files encoded with opustools 0.1.10/libopus 1.2.1, or if it did happen with older encodes, it only occurred at low bitrates. Subsequent testing has confounded this when I found some old files that had album artwork that were encoded with an older version of opustools but which didn't have problem playing back. I noticed that the artwork was abnormally small, at just 20KiB, and set out to test. That is how I came up with the 45.8KiB boundary. The largest JPEG I generated that worked was 45.6KiB, and the smallest that failed was 45.8KiB. I wanted to get more granular but quickly learned that generating JPEGs of such an exact file size is not trivial.
Attached are files bearing all this out, as well as the source flac, with the original album artwork. All files here were encoded using these parameters: "--quiet --bitrate 96 --vbr --ignorelength". I also did initial tests without --vbr and at higher bitrates, but got the same results, so I dropped them. There are two sets - turkish_march.7z, which got encoded at higher bitrates typical of music, and verse_of_the_rings.7z, which got encoded at lower bitrates typical of voice (but not in speex mode; we're still at ~50-60kbps or so). These are just excerpts of the complete files, but the complete files exhibit the same behavior.
Forum thread can be found here (though there's not much there...)
http://forums.rockbox.org/index.php/topic,52043.0.html
And note that yes, I understand that attaching large jpegs to puny opus files is a bit silly. But that doesn't mean the option shouldn't be there, particularly if one wished to encode at larger bitrates, for whatever reason.
This task depends upon

Comment by Rami Markus Maunula (Raimu) - Friday, 06 July 2018, 15:21 GMT
Can confirm this exact problem on Sansa Fuze 2, current release Rockbox.
Comment by Willliam W (Bilgus) - Monday, 31 December 2018, 10:53 GMT
bilditup1,

Thank you for your excellent bug report with sample files

this patch should fix the issue but needs testing

http://gerrit.rockbox.org/r/#/c/2046/

Loading...