• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Sansa Clip Zip
  • Severity High
  • Priority Very Low
  • Reported Version Release 3.14
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Rockbox
Opened by bilditup1 - 2017-10-29
Last edited by Bilgus - 2019-08-04

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

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…),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.

Closed by  Bilgus
2019-08-04 18:52
Reason for closing:  Fixed
Raimu commented on 2018-07-06 15:21

Can confirm this exact problem on Sansa Fuze 2, current release Rockbox.



Thank you for your excellent bug report with sample files

this patch should fix the issue but needs testing

William -

Only just saw that this got a response, heh. I had figured given how much time had passed without a response that Rockbox wasn’t really getting worked on much anymore - glad to be proven wrong!

‘Thank you for your excellent bug report with sample files’

You’re welcome! Thank *you* very much for fixing this issue! Works for me without any problems, though obv since you merged a long time ago you must have been confident about it. In any case - won’t have to make two separate transcodes anymore, hurray! :)



Available keyboard shortcuts


Task Details

Task Editing