Cavey wrote:
Total guess and hardly my area of expertise but I'd wager this will be something to do with the handling and size of a single track/file which can be cued or reviewed (forward or r versed). Thinking about it, in order to be able to do this reasonably quickly in real time, the entire file needs to be "loaded" as it were (especially as you listen to the speeded up cue/reverse as you do it), and >90 mins is an uncommonly long play, big file. The software will be expecting a finitely long file? This limitation must come into play at some point, but in which case it's a limitation, not a bug.
You may be on to something. I can't recall offhand how you seek within mp3 files but I can believe that you can't easily jump to arbitrary points in the file because lots of compression algorithms use information from the past to encode the current state (e.g. i-frames and b-frames in video codecs.) In other words, as you put it, the entire file has to be processed from the beginning. I can also believe the codec implementation in an old-ish car would already have been obsolete when it shipped, ie. is pretty outmoded now, so could suffer from limitations in this regard. (I'd argue it's still a bug, from the user's viewpoint, though; and that's all that really matters.)
If that's the case, it could be a buffer overflow or buffer truncation again, but when the head unit tries to seek to a point to resume playback instead.
Hmm, but on the other hand, if that was it, I wouldn't expect AE to be able to manually seek within the file, either, for the same reason... interesting.