Hi,

for fast readers points in this post are:

- Very slow start of APE files
- Readonly files don't rename on the fly


APE files in 0.9 are loading very slow for some reason. Some slower than others.
Slow meaning 5 seconds with laggy mouse while mp3 and flac codecs even with Full File Buffering 30MB start instantly. While testing this issue I used Full File Buffering at 0.

5sec start ape file details:
bitrate = 658
samplerate = 44100
channels = 2
bitspersample = 16
flags = 32
codec = Monkey's Audio
encoding = lossless
codec_profile = Insane
version = 3.99
tagtype = apev2
cue_embedded = no

Some other APE file are loading much faster but it still takes at least a second just to start.

1sec start ape file details:
bitrate = 862
samplerate = 44100
channels = 2
bitspersample = 16
flags = 22
codec = Monkey's Audio
encoding = lossless
codec_profile = Extra High
version = 3.97
tagtype = apev2
cue_embedded = no

So it's probably the version or profile used issue.
CPU AMD3500+, but it doesn't matter since mp3 and flac work like a charm.

And other tiny issue would be readonly files and renaming on fly.
Why not just remove readonly attribute from the file automatically, or at least popup with ignore all/retry/cancel instead of retry/cancel message box.

Pinging ASIO issue as well.

There, and thanks for the player.

APE is not officially/properly supported in 0.9 due to bugs in the monkey's audio code. It's recommended that you use a different format instead. Before I upgraded to 0.9 I transcoded everything to wavpack using .8.3. I found that using the wavpack -h setting the file sizes were much the same between ape and wavpack.

Edit: About the renaming issue: The point of readonly files is that they can't be modified/deleted/renamed. It would be irresponsible of foobar to automatically attempt to remove the readonly attribute (this is not always possible if you don't own the files), even if it prompted you first. If you want to modify files, then don't set them Read-only.

Ok about APE, I may use different, as a matter a fact I use FLAC 99% of the time, it's just I wanted to help by reporting it.

About readonly...I still think that ignore option would be great.
That readonly somehow got there, probably while I was moving from backup dvd or something, that's not the point. Why go to explorer and move it while you can do it with a click of a button.
You could told me to read file tags and rename myself

your problem purely exists because you use 'insane' mode for compression
i'm not sure what it is exactly that causes the slow initialisation of tracks (i imagine something like a lack of seek info in the insane preset, though it could be something else just as easily)..
'extra high' shouldn't give you this problem though (the difference in compressed sizes is utterly negligible btw), since EH plays instantly on my own 2800+ athlon.. (though perhaps you should upgrade those to 3.99 extra high encodes, i've never used 3.97, it might be slower to start)

Both flac and mp3 require far less cpu to decode, (they're asymmetric codecs, ie. encoding takes much longer than decoding, relatively speaking), while monkey's audio [symmetrical codec] was conceived of to provide very good compression at (what i consider to be) acceptable cpu use (it's about 3% for playback for 'extra high' here, i'm sure mp3 playback took more out of pc's when the 486 was still the main workhorse )

While it's true that MAC has some implementation problems because of bugs that have been reported but still aren't fixed (the reporting happened a while ago, but the developer seems to have lost interest a bit), for general use it should still be fine to use (i have about 240gb worth of encoded files, and no problems with it yet)


at -h the filesizes will be comparable if you used 'normal' compression on MAC, but it's not in the same league as 'extra high' compression, when it comes to compression (saying Wavpack/MAC compression on the high compression modes are comparable is just unfair towards MAC)