[GeneralDisarray]

The behaviour i described in my original post is evident in every conceivable configuration. I appreciate you devs are time pressed people, but i think it would be very informative if you tested it for yourself (ie any combination of cdimage .ape & .cue)

It would be satisfying to have at least one person who can verify this.

[DDDamian]

As noted, 1) and 3) are covered, 2) is not, nor will it likely get much attention.

a) it's in ffmpeg which is an external library which we are in the process of bumping up to the next revision and seldom patch as it's not our code
b) ape is really a dead format
c) there is very little impact for most users if at all

There have got to be programs out there which will batch convert those to flac for you faster than we can possibly come up with a fix that won't help many users nor progress the code much for the future. That and the fact that most devs prefer to split rips down to track level for better metadata embedding and scraping.

It's just not worth putting time into when conversion is easy and beneficial, sorry.

[GeneralDisarray]

that's fair enough. I'm resolved to the mother of all conversion tasks now. It does beg this question though.. if .ape is such a redundant format (that clearly finds little or no favour amongst XBMC users), why support it at all? There are many fine achievements and higher priorities in the XBMC universe, why accept such a flawed implementation? Better to be a master of all trades...

[taxigps]

thanks for your feedback taxigps. Are you referring to the issue where the track breaks do not align? DDDamian indicated (a few posts back) that a fix might be possible for this. Do you guys compare notes?

2) taxigps refers above to an issue in ffmpeg where part of the start of the .ape file appears to play before the selected track (according to the ticket

No, the problem is not the track breaks do not align. the problem is ffmpeg decoder can't seek to the exactly time point of ape file, so the track can't start at the right time point. It always seek to next timestamp now, and so clipping occurs.

[GeneralDisarray]

No, the problem is not the track breaks do not align. the problem is ffmpeg decoder can't seek to the exactly time point of ape file, so the track can't start at the right time point. It always seek to next timestamp now, and so clipping occurs.

if the problem is with ffmpeg then...

1) do you know if they have fixed it in the latest build?
2) if they have, how long before it can be incorporated into XBMC?

[DDDamian]

I don't see any mention of it in the changelog >here< but I may have missed it. At any rate I mentioned it to a Team member who's also on the ffmpeg team and a bleeding genius - no promises but he said he'd review this thread.

To actually get the change in (assuming it's in v10.0 of ffmpeg) you can compile from Elupus's github now, or wait another three-five weeks for it to hit the nightlies - the merge is being worked on now.

[GeneralDisarray]

that's very promising news DDDamian, thanks for your efforts

[GoEleven]

I kinda feel guilty to do a thread bump as a first post, but I'd like to report that as of Frodo RC2 the problem outlined in first post still persists. Also, to justify my bump I'm adding that WavPack+cue exhibits the very same behaviour. Flac+cue works fine. I myself will probably convert to flac, but it's still a functionality issue.

On a sidenote, is embedded cue not supported in wavpack or did I miss something?

Anyway, big kudos to dev team for the project - it's an amazing work, and such a level of user support is entirely unknown to many, many big companies selling really expensive software.