Rockbox

Tasklist

FS#11192 - FLAC with CUEsheet playback issues (reopening of FS#7354)

Attached to Project: Rockbox
Opened by Matthieu Mambrini (Matthieu) - Friday, 09 April 2010, 11:45 GMT
Task Type Bugs
Category Music playback
Status Unconfirmed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This is a reopening of issue  FS#7354  (quoted below) related to playback problems involving cuesheet support and flac files (labelled #1 in the original post). Jumps to certain positions in flac file according to the cuesheet fail consistently.

The bug is extensivelly described in the original report and can be easily reproduced in current versions. I reproduced it in many situations with the following configuration:

Equipment used: Cowon D2 and Cowon D2 simulation
Rockbox version: tested on r25508-100407 and r24777-100219 (simulation)
Rockbox settings: Cuesheet support ON, other on default
FLAC files: Ripped form my original CDs with EAC (to WAV and cuesheet) in secure mode and processed with FLAC 1.12 and/or 1.14 compression level 8. MD5 checksums on cuesheets and FLACS checked. Cuesheet syntax OK, cuesheet file encoding UTF8-DOS and/or DOS. Works properly my on computer.

Quote of the original post
====================

Full description of issue #1:
While playing certain (but not all) FLAC files with CUE support (played by navigating to FLAC file in "FILES" mode and pressing play), the "skip to next track" command won't work on certain tracks on that cuesheet, but will skip to other tracks on that CUE just fine. It occurs while in both "now playing" or "browse cuesheet" screen. When I try to skip to certain tracks on CUE, the current playback will stop for a moment and the icon indicates disk usage (just like normal) but it wont skip to appropriate position, just resume playback at current track/position. I have experienced this on multiple files, encoded with FLAC 1.12 and 1.14.

Issue #1 - Tested:
* Found two cases (FLAC + CUE files) in my collection (but I'm sure there are many more) that have this problem.
* These files play without a problem on my computer with Foobar2k and were securely ripped form original CD and encoded (with differnet FLAC versions), MD5 checksum-ed and CUEsheets checked for proper syntax - ALL FINE.

1.) I verified that the issue occurs while trying to navigate to track #9 in case of FLAC file A, and track #7 on FLAC file B. Track start times on both files are different, different lengths and don't seem to have some kind of "pattern" or to differ (in terms of length, index position,..) from tracks on cuesheet that skip-to normally.

2.) I substituted the A and B FLAC files with FLAC file C (which is a FLAC from a different CD) and preserved the original cuesheets A and B and tried to play FLAC C with these two cuesheets to confirm if it is a problem with a cuesheet. Everytrhing worked as it should and the problem did not occur. So I think that rules out the cuesheet as the only cause of the problem.

3.) I used both cuesheets A and B and both FLAC files A and B, but played FLAC A with cue B and vice-versa. Everything played OK, even on previously problematic positions. (of course the cuesheet info wasn't correct for that FLAC, since they were swapped, but skipping to tracks worked) That seemed to indicate that there might be a problem with a specific position/time in the FLAC file that the playback wont jump to.)

4) I altered both cuesheets from previous (3.) test so that I entered the correct/problematic INDEX of _one_ of the cuesheet tracks to match the track index of original cuesheet, so that it "hit" that problematic position. So While I played FLAC A with modified cue B (entered the problematic time/index of cue A to one of the tracks) the problem reoccured! I could not skip to that (altered) track position.
This led me to believe that this problem occurs when the track index in cuesheet "hits" a certain time/spot on a specific FLAC file.

5.) This time I checked what will happen if I use a third CUESHEET (from some other CD) on original A and B FLAC files. Everything worked OK. No surprise, as that third cuesheet did not have the track index time of that problematic position.

4.) This time I reencoded both A and B FLAC files with a different FLAC version (now 1.14, was 1.12) and tested again. Previously problematic tracked worked OK!
BUT problem started occuring on other tracks now, on file A on track #13, while FLAC B now had multiple problems: track #2, 5, 8, 14! This suggest that it is not an encoding problem.

Once again, these files work flawlessly on my computer and are proper lossless conversions (I also always use the VERIFY function while converting to/from FLAC)

So the conclusion would be: When cuesheet index of a track "hits" just the right position in a FLAC file, regardless of its encoding the issue will occur. Also, this also isn't an uncommon problem since I experienced it on 4 occasions and seems to be not-that-hard to find if you test several FLAC + cue combos.

I realize that this happens only with certain FLAC and track indexes COMBOS so it might be harder to recreate, but it really seems not that uncommon. And if not otherwise, I could supply the FLACS in questions (but each is several hundred MBs long and may be illegal to distribute it). I believe it can be recreated with just about any FLAC file, by finding a proper CUEsheet track index. It would be highly unusual that it would happen so frequent in my collection if it was an "isolated case" and I honestly believe it has nothing to do with FLAC or CUE files and that they are encoded correctly and accurately.
This task depends upon

Comment by ptrkmj (ptrkmj) - Tuesday, 17 May 2011, 20:43 GMT
It's been so many years since the issue was raised. It's definitely not an isolated case.

Personally, I find it very disturbing. Yet most people don't use cuesheets so that might be the reason for lack of interest from developers.

I wonder if anybody can look into that (I wish I could).

I can provide files for recreation of the problem.
Comment by aquataine (aquataine) - Friday, 27 July 2012, 05:00 GMT
I find it very disturbing also because I really depend on this feature (that's one of the reason that makes me switch from OF - the other is crossfeed).
From my investigation, it doesn't relate with encoding. I have tried encoding with libflake, and the problem still occurs, but on different tracks.
Libflake encodes to smaller size, so I think this bug relates to buffering.

Loading...