[Derek Dagit]

... and if it does, there are almost always loud
hiccups in playback. I have tried `flac -8 -V` on many
different wav files both in windows and in linux, but
there doesn't seem to be a difference. There do seem
to be certain parts of the file where verification will
fail; about one or two spots in a 4-minute song.
Changing -8 to another number seems to cause
verification to fail at different parts of the file.
Encoding long files would be nearly impossible :)

• assigned_to: nobody --> jcoalson

Logged In: NO

I do also have this particular problem:
System is a Athlon TB 1133MHz (FSB133) on Asus A7V133.
Encoding long files is nearly impossible due to repeated
verify errors.
I have checked RAM with memtest86, but there seem to be no
problems. Systems stays cool and is not overclocked.

No other calculation intensive programs (lame, musepack,
vorbis) have any problems on this system ...

Logged In: YES
user_id=694606

Curious, I am running an Athlon TB 1.4 on an A7V133.

Logged In: NO

Meanwhile I got another comment from a user with a 1 Ghz
Athlon TB on a Asus A7V133 in a german newsgroup - he has
the same problems.

Also I noticed on my system (the 1133Ghz Athlon TB), that by
setting the FSB down to 100MHz the problem seems to vanish.
But this slows the CPU down to 850 MHz, of course ...

Logged In: NO

by the way: the failure happens more often in higher
compression modes. Using "-2" or lower, the problem also
seems to vanish.

e-mail: jenzd@gmx.de (the one with 1133Mhz Athlon)

Logged In: YES
user_id=694606

Good call about the FSB frequency. I throttled mine down
to 100MHz on my A7V133, and `flac -8 -V` encoded a 30-minute
song, among others, with no errors.

I also noticed higher failure rates corresponding to higher
quality parameters.

My CPU has never been overclocked.

Logged In: NO

To test my system once more, I have run the "Torture Test"
of Prime95 for ca. 26 hours, which is known to find many
subtle hardware instabilities (CPU/RAM). The system seems to
be totally stable.

IMHO there must be a special issue with FLAC on the Asus
A7V133. And as no other CPU/RAM-intensive program seem to
have any problems on this platform, I am somehow convinced
that the problem could be solved for a future version of
FLAC. At least it should be reproducible on any
A7V133-system with an Athlon TB processor and FSB set to 133
Mhz.

If any further tests/comments are needed, feel free to
e-mail me:
jenzd@gmx.de

Logged In: YES
user_id=24141

Trying out FLAC for the first time I was saddened to see
VERIFY errors. My system is also an Athlon 1.4 on an ASUS
A7V133 board.

This system has been extremely stable for years, but I will
try running memtest86 all night just to see if it finds any
problems.

I didn't see any mention of OS or compiler here... I'm
running Gentoo Linux with GCC 3.3.4. My CFLAGS="-O3
-march=athlon -fomit-frame-pointer -funroll-loops -pipe"

-james

Logged In: YES
user_id=24141

My system completed 15 hours of memtest86 with no errors (16
passes). I also tried running flac repeatedly on the same
sans the -V flag, and the file size and checksum would
change occasionally, so it is not just a problem the verify
function.

Along the same lines, running flac -t repeatedly against a
set of files were verified during encoding will occasioanlly
yield an MD5 error.

Logged In: NO

Yes, same on my computer. Even if the files are verified ok,
sometimes the data doesn't match the original file. Also
there are occasional problems during playback using the
WinAmp-Plugin (strange sounds).
BTW, the problem obviously doesn't depend on a special
compiler or operating system ...

jenz (jenzd@gmx.de)

• status: open --> closed-invalid