Hydrogenaudio Forums > Monkey : is it useful to turn on "automatically verify&

Full Version: Monkey : is it useful to turn on "automatically verify&

Hydrogenaudio Forums > Lossless Audio Compression > Lossless / Other Codecs

anubis

Aug 5 2002, 08:39

I have a very low Cpu so it's very boring for me to verify each file.
Isn't it enough to turn on "stop processing after encountering an error" ?

Garf

Aug 5 2002, 08:51

If you are 100% sure your computer is working fine, then it's ok. But I thought the same and lost an album when several files got corrupted by a buggy chipset.

--
GCP

anubis

Aug 5 2002, 09:09

Okay but if "stop processing after encountering an error" is on and then my file got entirely compressed, doesn't it mean that no error occured ?

Frank Klemm

Aug 5 2002, 09:33

QUOTE

Originally posted by Garf
If you are 100% sure your computer is working fine, then it's ok. But I thought the same and lost an album when several files got corrupted by a buggy chipset.
--
GCP

If you have enough RAM "automatic verify" do not verify the data on HD, but only in RAM.
So it has no chance to detect problems in the PCI/IDE subsystem.

But I don't found any code to force reading from disk (instead reading from cache)
and to force flusing the disk buffer of a given file handle. Not for Linux nor for Windows
95/98/ME/XP/NT/2K.

madah

Aug 5 2002, 10:16

There's always the possibility to restart the computer after compressing an album with monkeys (remember to leave source files intact just in case). Then verify the files...

It can also be used to test the stability of your computer; Compress ~5-10 cds with "Extra High" in Monkeys then restart & verify.

If you have several partitions/harddisks (and lots of free space) try this:
Compress your entire C: with WinRar or WinAce (use maximum compression), put the compressed file to D:. At the same time, compress D: and save the file to C:. This will stress-test your entire system. Afterwards, restart and verify both the compressed files.

Note: Let winrar/winace load the filelist first, otherwise it will lock itself up in an endless loop, trying to compressed the other compressed file (which is also growing...)

madah

Aug 7 2002, 15:12

QUOTE

Originally posted by Frank Klemm
But I don't found any code to force reading from disk (instead reading from cache)
and to force flusing the disk buffer of a given file handle. Not for Linux nor for Windows
95/98/ME/XP/NT/2K.

Actually you can... at least for NT/2K/XP. By using CreateFile(), specify FILE_FLAG_NO_BUFFERING or FILE_FLAG_WRITE_THROUGH as dwFlagsAndAttributes.

Taken from the helpfile:

QUOTE

FILE_FLAG_WRITE_THROUGH
Instructs the operating system to write through any intermediate cache and go directly to the file. The operating system can still cache write operations, but cannot lazily flush them.

FILE_FLAG_NO_BUFFERING
Instructs the operating system to open the file with no intermediate buffering or caching. This can provide performance gains in some situations.
An application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING:
· File access must begin at offsets within the file that are integer multiples of the volume's sector size.
· File access must be for numbers of bytes that are integer multiples of the volume's sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1024, or 2048 bytes, but not of 335, 981, or 7171 bytes.
· Buffer addresses for read and write operations must be aligned on addresses in memory that are integer multiples of the volume's sector size.
An application can determine a volume's sector size by calling the GetDiskFreeSpace function.

Destroid

Aug 7 2002, 17:13

QUOTE

Originally posted by anubis
Okay but if "stop processing after encountering an error" is on and then my file got entirely compressed, doesn't it mean that no error occured ?

I'm not 100% on this but I'd say no. The usual errors that would stop on are: out of disk space; if you had "delete source" and it was read-only file; if the WAV was corrupt; or if the WAV was incompatible with Monkey's (i.e. 32-bit).

Seems like overclocking, flakey RAM and crappy chipsets will let compression errors slip through without warning. I have always given the advice that if you get CRC errors even when it appears to have finished correctly to lower FSB speed and adjust the CPU multiplier to something where you have equivalent clock speed. Monkey's is the only program that seemed to indicate my machine was unstable at normal settings, now that's it's underclocked Monkey's works perfectly.

edit: Just recently I noticed that read-only files won't trip an error, at least not when I used Convert (APE->APE) using the Overwrite File option. What I just got was a whole lot of MAC temp().ape files along left with the source APE's.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.