I notice that when I use the Monkey's Audio GUI and Extra High compression that the encoding goes at one speed for approximately 50% of the file then speeds up and blasts through the rest of the file rather quickly. I'm not complaining or anything, I'm just curious as to why it works this way. Does it use information it gathers in the first half of the file to speed up the last half? If so, what does that mean for the quality or compression ratio? (I know lossless is lossless is lossless, but if it doesn't "pay attention" to the rest of the file couldn't there be some drawbacks?) What about a song like Bohemian Rhapsody that changes styles throughout the song?

Color me curious! Any ideas?

Hold on… I just noticed that it may be just a view issue. The % complete seems to jump by around 2% per update during the first half of the file and then switch to 0.5% per update the last half. That makes it look faster but it’s really just updating the display more often. Why would it do that?

You probably have "auto verify" enabled in the options. On some hardware (older versions of?) MAC produced corrupt files without warning. That's why auto verify was implememted. I guess if you successfully have created a large number of ape files without errors allready, it is safe to turn this option off an gain some more speed, however I'm not sure. Leave it on if you want to be safe.

OH! So the last 50% is the verify process. I was wondering when that happened! Good to know!

I always thought the GUI program read the whole file and then performed en/de-coding. Maybe I'm incorrect, but then wouldn't encoding occur during the latter-50% and be affected by auto-verify? Would changing the compression level also affect 51-100% progress in terms of speed?

The first 50% are for encoding the file (as was said earlier in this thread), the last 50% for verifying the file (the encoded file is decoded again and compared to the original). Since the encoded file is decoded during the verify phase the compression level will also affect the speed of the verify phase.
You can verify that the last 50% is used for verification by disabling auto-verify and encoding some files, the time it takes to compress a file will then be equal to the time it takes the GUI to go through the first 50% when auto-verify is enabled.

Sure.

I don't use auto-verify. A while back I used to manually verify all files. After using Monkey's for so long and working with some of the people who knew more about it that me I finally beat all the bugs out of my system and no longer have to verify at all anymore. Verify is a waste of time unless the machine is severely bugged.

What I mentioned in my earlier post was I observed that (when auto-verify is off) 0-50% was reading-in the file and 51-100% was writing-out the converted file.

So would that mean that if you used auto verify...

0-25% = read file
25-50% = encode file
50%-100% = verify file

No, I don't think so. Jasper was not entirely correct.

1: 0-50% Read into memory
2: 51-100% convert/writeout

If you have auto-verify on it verified in memory during step 2.

I mentioned this already in the MA forum, but if you have some sort of disk transfer corruption occurs auto-verify will not save you because it only checks the integrity of the compressed blocks in memory.

Then again, is anybody here not just guessing? I'm just offering my theory based on the behavior of the program.