error of cyclic redundancy on BIG sound recording program : savingfail offently !

Hi,


Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops, infinitly, so that
we can save our work if needed - if something good, live, happens ....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files (for 15 hours,
thats it) ..

The problem is when we save, sometimes the app crashes, saying
"temporary file too short" or sometimes "data chunk truncated".. And if
i analyse the temp, I see that just 3 errors in the 4000 small files is
enough to destroy all the archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from the authors of
the app : they NEVER write, i try to reach them since years ...

I use a 150 GB IDE drive dedicated for the temp of the prog, and I
offently do a chkdsk /f on it : its shows no errors, besides it seems to
repair some small errors (It brings less errors in trying to copy / cut
the temp to rebuild a part of the lost recordings)

I'm confused.
So, i just had the idea of re-format the drive with a larger cluster
size, and thats my question : is it a good thing for a HEAVY disk
writing process ? - don't forget the prog is running 24/7/365

What other "drive solution" should i adopt ?
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

Thanks in advance

Julien

"Setup.exe" wrote in message
...
Hi,

Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops, infinitly, so that we
can save our work if needed - if something good, live, happens ....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files (for 15 hours,
thats it) ..

The problem is when we save, sometimes the app crashes, saying "temporary
file too short" or sometimes "data chunk truncated".. And if i analyse the
temp, I see that just 3 errors in the 4000 small files is enough to
destroy all the archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from the authors of
the app : they NEVER write, i try to reach them since years ...

You could try asking for your money back, that might get a response.

I would try sending a polite email to every email address you can find on
their website, asking for assistance.

I use a 150 GB IDE drive dedicated for the temp of the prog, and I
offently do a chkdsk /f on it : its shows no errors, besides it seems to
repair some small errors (It brings less errors in trying to copy / cut
the temp to rebuild a part of the lost recordings)

Whilst chkdsk is good, you can often get an idea of whether there might be
disk related errors by looking in the System event log - run up event viewer
and them skim through the System event log. Ignore information and warning
messages, and (for now) any errors that aren't disk related. I suspect there
won't be but if there are any disk related errors recorded then that would
indicate a hardware related issue somewhere.

The next time you get an error, go straight to the system event log and have
a look to see if anything has been reported there.

I'm confused.
So, i just had the idea of re-format the drive with a larger cluster size,
and thats my question : is it a good thing for a HEAVY disk writing
process ? - don't forget the prog is running 24/7/365

Whilst I haven't use this software or experienced these specific errors, I
have encounted odd errors before now with a variety of applications which
generate files and which are long running. This might be a red-herring, but
I wonder whether disk fragmentation might be an issue - either disk
fragmentation or directory fragmentation. Given that the individual files
are probably quite small (4MB ish?) then I doubt file fragmentation is an
issue, but I wonder whether directory fragmentation might be a problem?
Could you download contig from
http://technet.microsoft.com/en-us/s.../bb897428.aspx and then at
the command line do

contig temp-path
and, just for completeness
contig -s temp-path

The first will defrag the directory entry, the second the files in it. Most
normal disk defragmenters won't defragment the directory entry, whereas
contig will. I've seen fragmentation cause quite a few products to fail, and
it can be hard to track down - but admitedly only when its dealing with a
very large very fragmented file and not lots of small individual ones.

What other "drive solution" should i adopt ?
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

If you do get it sorted please post back what the issue and resolution were.
--
Brian Cryer
http://www.cryer.co.uk/brian

Le 6/29/2012 4:02 PM, Brian Cryer a écrit :
"Setup.exe" wrote in message
...
Hi,

Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops, infinitly, so
that we can save our work if needed - if something good, live, happens
....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files (for 15
hours, thats it) ..

The problem is when we save, sometimes the app crashes, saying
"temporary file too short" or sometimes "data chunk truncated".. And
if i analyse the temp, I see that just 3 errors in the 4000 small
files is enough to destroy all the archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from the authors
of the app : they NEVER write, i try to reach them since years ...

You could try asking for your money back, that might get a response.

I would try sending a polite email to every email address you can find
on their website, asking for assistance.

I did that already, they are deaf.
Even worst, obviously their prog is totally out of date, perhaps its the
reason its fails. There is no recent upgrade. Some windows in the prog
just refer to Win98 system files, and of course that works not.

Besides, its a mess cause the app could be (or is) excellent, and i have
never seen such an equivalent


I use a 150 GB IDE drive dedicated for the temp of the prog, and I
offently do a chkdsk /f on it : its shows no errors, besides it seems
to repair some small errors (It brings less errors in trying to copy /
cut the temp to rebuild a part of the lost recordings)

Whilst chkdsk is good, you can often get an idea of whether there might
be disk related errors by looking in the System event log - run up event
viewer and them skim through the System event log. Ignore information
and warning messages, and (for now) any errors that aren't disk related.
I suspect there won't be but if there are any disk related errors
recorded then that would indicate a hardware related issue somewhere.

The next time you get an error, go straight to the system event log and
have a look to see if anything has been reported there.

Oh yes : tons of RED disk error : " Device bla bla has a bad bloc"
(Event 7) Ok, but when running CHKDSK, it says all is ok : no bad
sector. Would the term bad bloc" be different from "bad sector" and not
advised by the check disk log result ???


I'm confused.
So, i just had the idea of re-format the drive with a larger cluster
size, and thats my question : is it a good thing for a HEAVY disk
writing process ? - don't forget the prog is running 24/7/365

Whilst I haven't use this software or experienced these specific errors,
I have encounted odd errors before now with a variety of applications
which generate files and which are long running. This might be a
red-herring,

red-herring : what that means ?

but I wonder whether disk fragmentation might be an issue -
either disk fragmentation or directory fragmentation. Given that the
individual files are probably quite small (4MB ish?)

Even smaller : 512 kb !


then I doubt file
fragmentation is an issue, but I wonder whether directory fragmentation
might be a problem? Could you download contig from
http://technet.microsoft.com/en-us/s.../bb897428.aspx and then
at the command line do

contig temp-path
and, just for completeness
contig -s temp-path

The first will defrag the directory entry, the second the files in it.
Most normal disk defragmenters won't defragment the directory entry,
whereas contig will. I've seen fragmentation cause quite a few products
to fail, and it can be hard to track down - but admitedly only when its
dealing with a very large very fragmented file and not lots of small
individual ones.

As the disk is always writing (recording in fact), I'm not sure its good
the defragment it at the same time ... But I'll make my mind about this
test.

What other "drive solution" should i adopt ?
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

If you do get it sorted please post back what the issue and resolution
were.

Ok, thanks for the reply.
I first have to check this "bad bloc" errors ...

Setup.exe wrote:

Hi,

Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops, infinitly, so that
we can save our work if needed - if something good, live, happens ....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files (for 15 hours,
thats it) ..

The problem is when we save, sometimes the app crashes, saying
"temporary file too short" or sometimes "data chunk truncated".. And if
i analyse the temp, I see that just 3 errors in the 4000 small files is
enough to destroy all the archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from the authors of
the app : they NEVER write, i try to reach them since years ...

I use a 150 GB IDE drive dedicated for the temp of the prog, and I
offently do a chkdsk /f on it : its shows no errors, besides it seems to
repair some small errors (It brings less errors in trying to copy / cut
the temp to rebuild a part of the lost recordings)

I'm confused.
So, i just had the idea of re-format the drive with a larger cluster
size, and thats my question : is it a good thing for a HEAVY disk
writing process ? - don't forget the prog is running 24/7/365

What other "drive solution" should i adopt ?
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

Thanks in advance

Julien

From their web site:

Loop Recorder has 64bit support to handle recorded audio data of up to
16 GB.

Loop Recorder Pro can handle even larger amounts of audio data. With a
FAT32-filesystem it can record audio data of up to 256 GB per session
and with NTFS it is unlimited.

So you must be using their Standard version and not their Pro version.
Or have you been indefinitely using their free trial version which does
not include support?

The Pro version has the archive function, not the Standard version (and
very probably not the trial version).

Changing cluster size won't affect a defect in the 'Save' algorithm in
the program to close any files on which it has a handle. From
http://www.looprecorder.de/tut_radio.php, it appears you don't just save
the recording but instead you open an editor and from there you do a
save function. http://www.looprecorder.de/tut_editor.php shows the
editor that should open when you click "Edit and Save". Are you doing
any editing before you click the Save button (disk icon in toolbar)?

Are you clicking on the "Edit and Save" button in the Loop Recording
dialog or are you instead bringing up the editor and saving from there
without first stopping the looped recording? Presumably you must first
stop recording before you start editing and then save.

What "3 errors" are you talking about (in the temp folder with the 4000
files)? What was this "analysis" you mention?

Do you really need to generate 4000 files for 15 hours of recording?
From their product description, it looks like you can create some huge-
sized audio files the limit on size depending on which file system you
use for the drive. http://www.looprecorder.de/tut_diskusage.php shows
file sizes up to about 300GB which is obviously a lot larger than your
"small files" comment. How big is your loop? Are you leaving it at the
small default of 10 minutes? Or did you up it to hours? I don't see
the program is restricted from going up to your 15 hour window but then
I cannot see the parameters you can specify when you click on Change
button for Time Settings in the Loop Recorder dialog (shown at
http://www.looprecorder.de/tut_radio.php). You aren't hitting a maximum
file count limit per folder in the file system but you might be hitting
a maximum object count in the program.

Since you are talking about capturing "live" content then you're talking
about people talking on your show (you don't mention what your show airs
so maybe "live" content is local talent coming into your studio to play
their music). If it's just talking you want to capture, you could lower
the bitrate to reduce the size of the audio file(s). Their diskusage
web page show how much difference there is in size the audio files with
different bitrates. You never mentioned how long is the actual loop
that you are recording but having 4000 audio files sure makes it appear
you chose a small loop size. My guess is that each loop is generating
an audio file. So make the loops longer. If you think the audio files
are then getting too big then reduce the bitrate for capture.

Well, it's possible you're hitting a max file count per folder depending
on what file system you are using on the drive but which you never
mentioned. http://en.wikipedia.org/wiki/Fat32 has a table that shows
the maximum number of files (per folder). If you using the old FAT12
file system, the max is 4068 files per folder. You didn't even mention
which operating system you are using. So what OS and what file
system(s) within it are you using?

Are you running an anti-virus program or anything else that interrogates
the files on your computer? If so, have you tried excluding this
program's "temp" folder?

You tried all their contacts at http://www.looprecorder.de/email.php,
even the postal address (by sending your letter with signature
confirmation to prove they got it), and they didn't reply? Support
should be included in the paid product. You did pay for it, right, and
you're not just indefinitely using their trial product, right?
Personally I get suspicious of any company proliferating commercialware
that hides behind a private domain registration (their registrar is
listed as the registrant instead of the real registrant) to hide their
identity. looprecorder.de's registration shows their registrar (1and1)
as the registrant. Registrants pay extra to hide.

Setup.exe wrote:
Le 6/29/2012 4:02 PM, Brian Cryer a écrit :
"Setup.exe" wrote in message
...
Hi,

Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops, infinitly, so
that we can save our work if needed - if something good, live, happens
....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files (for 15
hours, thats it) ..

The problem is when we save, sometimes the app crashes, saying
"temporary file too short" or sometimes "data chunk truncated".. And
if i analyse the temp, I see that just 3 errors in the 4000 small
files is enough to destroy all the archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from the authors
of the app : they NEVER write, i try to reach them since years ...

You could try asking for your money back, that might get a response.

I would try sending a polite email to every email address you can find
on their website, asking for assistance.

I did that already, they are deaf.
Even worst, obviously their prog is totally out of date, perhaps its the
reason its fails. There is no recent upgrade. Some windows in the prog
just refer to Win98 system files, and of course that works not.

Besides, its a mess cause the app could be (or is) excellent, and i have
never seen such an equivalent


I use a 150 GB IDE drive dedicated for the temp of the prog, and I
offently do a chkdsk /f on it : its shows no errors, besides it seems
to repair some small errors (It brings less errors in trying to copy /
cut the temp to rebuild a part of the lost recordings)

Whilst chkdsk is good, you can often get an idea of whether there might
be disk related errors by looking in the System event log - run up event
viewer and them skim through the System event log. Ignore information
and warning messages, and (for now) any errors that aren't disk related.
I suspect there won't be but if there are any disk related errors
recorded then that would indicate a hardware related issue somewhere.

The next time you get an error, go straight to the system event log and
have a look to see if anything has been reported there.

Oh yes : tons of RED disk error : " Device bla bla has a bad bloc"
(Event 7) Ok, but when running CHKDSK, it says all is ok : no bad
sector. Would the term bad bloc" be different from "bad sector" and not
advised by the check disk log result ???


I'm confused.
So, i just had the idea of re-format the drive with a larger cluster
size, and thats my question : is it a good thing for a HEAVY disk
writing process ? - don't forget the prog is running 24/7/365

Whilst I haven't use this software or experienced these specific errors,
I have encounted odd errors before now with a variety of applications
which generate files and which are long running. This might be a
red-herring,

red-herring : what that means ?

but I wonder whether disk fragmentation might be an issue -
either disk fragmentation or directory fragmentation. Given that the
individual files are probably quite small (4MB ish?)

Even smaller : 512 kb !


then I doubt file
fragmentation is an issue, but I wonder whether directory fragmentation
might be a problem? Could you download contig from
http://technet.microsoft.com/en-us/s.../bb897428.aspx and then
at the command line do

contig temp-path
and, just for completeness
contig -s temp-path

The first will defrag the directory entry, the second the files in it.
Most normal disk defragmenters won't defragment the directory entry,
whereas contig will. I've seen fragmentation cause quite a few products
to fail, and it can be hard to track down - but admitedly only when its
dealing with a very large very fragmented file and not lots of small
individual ones.

As the disk is always writing (recording in fact), I'm not sure its good
the defragment it at the same time ... But I'll make my mind about this
test.

What other "drive solution" should i adopt ?
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

If you do get it sorted please post back what the issue and resolution
were.

Ok, thanks for the reply.
I first have to check this "bad bloc" errors ...


There is an article here for "bad block" Event 7.

http://www.symantec.com/business/sup...t&id=TECH16938

The Sense Code is in the numeric information stored in the Event. You
convert the numbers, into a text string, to gain a better understanding
of the error type.

*******

Download HDTune (version is good enough for this purpose)

http://www.hdtune.com/files/hdtune_255.exe

Install it, and then run it. Select the recording disk drive from the menu.

Then, click the "Health" tab.

The disk drive "Health" is reported by the SMART statistics system
on the hard drive.

http://en.wikipedia.org/wiki/S.M.A.R.T.

The display may already indicate (by red/yellow/green colors), there is a
problem. Some of the yellow indicators are not truthful - do not panic
immediately, if the display has some colors. Even my brand new drives,
have yellow entries that should be ignored.

Check "Reallocated Sector Count" first. The first line of numbers, is
from a brand new Seagate hard drive. The second line of numbers, is
from my failing Seagate 500GB drive. The second line is meant to indicate
what a degradation of the hard drive looks like. First, the Data value
rises, and when it gets high enough, the columns on the left start
to decrement. The left hand column is an indication of useful life, as
in there is "98 %" of life in terms of reallocation of sectors.

Current Worst Threshold Data Status

100 100 36 0 OK

98 98 36 104 OK

It would seem, in this case, that "Data" is the raw count. The columns
on the left, changed from 100 to 98, the day that Data passed the 100
mark. I interpret this trend to mean that the "total life" of the drive
is roughly (100-36)/(100-98) * 104 = 3328 reallocated sectors. My disk
is still "OK" as far as the status indicator is concerned, and the color
will change when the "Data" column hits greater than roughly 3200. It
took a bad drive, for me to get a demonstration of how it works.

The second indication is "Current Pending Sector". The status here, has
not changed for me, since I purchased the drive. Current Pending Sector
is a queue of sectors that need correction by the controller card. It
seems on my drive, that the queue never grows, and when a problem
occurs on the drive (on write), it is fixed immediately. This queue
is supposed to grow, when a read failure occurs, and the sector is
scheduled for repair, on the next write operation. The "Data" column
will return to zero, when the sector is processed and reallocated
or not. A write attempt for the sector is needed, before it can
be repaired. A sudden increase in "Data" here, could happen just
before the "Reallocated" starts to grow.

Current Worst Threshold Data Status

100 100 0 0 OK

In terms of health of the drive, and safety of the data, I replace
the hard drive, as soon as "Reallocated Sector Count" and the
Data column value is no longer 0. My drive still has not failed,
and has been running for about a week after the Data column showed
a problem.

But hard drives can cease to function, very quickly, so the problem
should not be ignored. Make a backup copy of the contents of the
hard drive, on a second disk somewhere. Like you would, for normal
backup procedures for the computer. Then, if the drive fails completely,
you can restore anything you need.

There is a "level of dishonesty" about "Reallocated Sector Count".
When the drive leaves the factory, there can be 500,000 reallocated
sectors on the drive. And the "Data" column would show 0. The manufacturer
does not want you to know, about the level of factory defects.
So the statistic is skewed, and is likely not completely linear.
As users, we cannot tell, whether my example of "104" above, is
104 actual sectors, or some other number (i.e. scaled math).

*******

If the disk drive has a problem, then the software designers at
looprecorder.de are not guilty. They cannot assume a defective drive,
and use QuickPar to try to improve the error rate. It's not a valid
design objective. It would be a valid objective, for a space craft
flying through space, where storage devices could fail while the
space craft is in flight. Here on Earth, we replace disk drives
when they become defective. I have replaced my disk drive, within
the last week, because of problems.

When "Reallocated Sector Count" grows, the peak write rate of the
hard drive, will fall. Performance will be "choppy". If the drive
takes 15 seconds to complete a write operation, because of bad sectors,
recording samples from looprecorder could be lost.

*******

If you wish to test another recording application, there is
Audacity from audacity.sourceforge.net.

http://audacity.sourceforge.net/

It can be configured, to write sound samples into files, for
later analysis. If you suspect looprecorder is not functioning
well, that might be a free alternative.

*******

The Windows built-in Sound Recorder, stores recorded sound in
system RAM. And the recording duration is limited by available
RAM.

Other recording programs, may initially store sound in RAM,
and then transfer blocks of data into files on the file system.
There should in fact, be plenty of time to resolve write problems
to the disk, due to the large buffer space provided by system
RAM. But it could be, that an error code, returned after a 15 second
attempt to write, causes the recording program to throw away
that segment of recorded data. And then, you see a corresponding
Event Viewer entry, for the failure that the operating system logged.

Summary: Get a new hard drive.
Replace the existing drive, before it fails.
You can use the old drive as a backup device, but knowing
it could fail at any time, and cannot be "trusted".

Paul

On 6/29/2012 6:51 AM, Setup.exe wrote:
Hi,


Got a big big problem :
I'm working on FM radio Station.
We use a small german prog to record 15 hours loops,
infinitly, so that we can save our work if needed - if
something good, live, happens ....
Here is the prog : http://www.looprecorder.de/

This app uses a special method of disk writing :
is creates a TEMP folder with 8 x 500 of small wav files
(for 15 hours, thats it) ..

The problem is when we save, sometimes the app crashes,
saying "temporary file too short" or sometimes "data chunk
truncated".. And if i analyse the temp, I see that just 3
errors in the 4000 small files is enough to destroy all the
archive saving process ..

Thats awfull !!!

All the more, its just impossible to have any answer from
the authors of the app : they NEVER write, i try to reach
them since years ...

I use a 150 GB IDE drive dedicated for the temp of the prog,
and I offently do a chkdsk /f on it : its shows no errors,
besides it seems to repair some small errors (It brings less
errors in trying to copy / cut the temp to rebuild a part of
the lost recordings)

I'm confused.
So, i just had the idea of re-format the drive with a larger
cluster size, and thats my question : is it a good thing for
a HEAVY disk writing process ? - don't forget the prog is
running 24/7/365

What other "drive solution" should i adopt ?.
Take a sata drive ? A special drive ? An SSD ?
I really don't know.
Hope someone can help ...

Thanks in advance

Julien

You really should be running a better checking program than
chkdsk. I would suggest SpinRite. If there are any disk
problems it will find them.
http://www.grc.com/sr/spinrite.htm

There is an article here for "bad block" Event 7.

http://www.symantec.com/business/sup...t&id=TECH16938

The Sense Code is in the numeric information stored in the Event. You
convert the numbers, into a text string, to gain a better understanding
of the error type.

*******

Download HDTune (version is good enough for this purpose)

http://www.hdtune.com/files/hdtune_255.exe

Install it, and then run it. Select the recording disk drive from the menu.

Then, click the "Health" tab.

The disk drive "Health" is reported by the SMART statistics system
on the hard drive.

http://en.wikipedia.org/wiki/S.M.A.R.T.

The display may already indicate (by red/yellow/green colors), there is a
problem. Some of the yellow indicators are not truthful - do not panic
immediately, if the display has some colors. Even my brand new drives,
have yellow entries that should be ignored.

Check "Reallocated Sector Count" first. The first line of numbers, is
from a brand new Seagate hard drive. The second line of numbers, is
from my failing Seagate 500GB drive. The second line is meant to indicate
what a degradation of the hard drive looks like. First, the Data value
rises, and when it gets high enough, the columns on the left start
to decrement. The left hand column is an indication of useful life, as
in there is "98 %" of life in terms of reallocation of sectors.

Current Worst Threshold Data Status

100 100 36 0 OK

98 98 36 104 OK

It would seem, in this case, that "Data" is the raw count. The columns
on the left, changed from 100 to 98, the day that Data passed the 100
mark. I interpret this trend to mean that the "total life" of the drive
is roughly (100-36)/(100-98) * 104 = 3328 reallocated sectors. My disk
is still "OK" as far as the status indicator is concerned, and the color
will change when the "Data" column hits greater than roughly 3200. It
took a bad drive, for me to get a demonstration of how it works.

The second indication is "Current Pending Sector". The status here, has
not changed for me, since I purchased the drive. Current Pending Sector
is a queue of sectors that need correction by the controller card. It
seems on my drive, that the queue never grows, and when a problem
occurs on the drive (on write), it is fixed immediately. This queue
is supposed to grow, when a read failure occurs, and the sector is
scheduled for repair, on the next write operation. The "Data" column
will return to zero, when the sector is processed and reallocated
or not. A write attempt for the sector is needed, before it can
be repaired. A sudden increase in "Data" here, could happen just
before the "Reallocated" starts to grow.

Current Worst Threshold Data Status

100 100 0 0 OK

In terms of health of the drive, and safety of the data, I replace
the hard drive, as soon as "Reallocated Sector Count" and the
Data column value is no longer 0. My drive still has not failed,
and has been running for about a week after the Data column showed
a problem.

But hard drives can cease to function, very quickly, so the problem
should not be ignored. Make a backup copy of the contents of the
hard drive, on a second disk somewhere. Like you would, for normal
backup procedures for the computer. Then, if the drive fails completely,
you can restore anything you need.

There is no back up to do, as the entire drive is dedicated to the temp
of the Loop Recorder. There is no other data in it, saves are made on
another drive.



There is a "level of dishonesty" about "Reallocated Sector Count".
When the drive leaves the factory, there can be 500,000 reallocated
sectors on the drive. And the "Data" column would show 0. The manufacturer
does not want you to know, about the level of factory defects.
So the statistic is skewed, and is likely not completely linear.
As users, we cannot tell, whether my example of "104" above, is
104 actual sectors, or some other number (i.e. scaled math).

*******

If the disk drive has a problem, then the software designers at
looprecorder.de are not guilty. They cannot assume a defective drive,
and use QuickPar to try to improve the error rate.

Of course, yes.


It's not a valid
design objective. It would be a valid objective, for a space craft
flying through space, where storage devices could fail while the
space craft is in flight. Here on Earth, we replace disk drives
when they become defective. I have replaced my disk drive, within
the last week, because of problems.

When "Reallocated Sector Count" grows, the peak write rate of the
hard drive, will fall. Performance will be "choppy". If the drive
takes 15 seconds to complete a write operation, because of bad sectors,
recording samples from looprecorder could be lost.

*******

If you wish to test another recording application, there is
Audacity from audacity.sourceforge.net.

http://audacity.sourceforge.net/

It can be configured, to write sound samples into files, for
later analysis. If you suspect looprecorder is not functioning
well, that might be a free alternative.

We absolutly need an automation recording in loop mode, and 15 hours
during is a minimum. Not sure its easy to get that from other software.



*******

The Windows built-in Sound Recorder, stores recorded sound in
system RAM. And the recording duration is limited by available
RAM.

Other recording programs, may initially store sound in RAM,
and then transfer blocks of data into files on the file system.
There should in fact, be plenty of time to resolve write problems
to the disk, due to the large buffer space provided by system
RAM. But it could be, that an error code, returned after a 15 second
attempt to write, causes the recording program to throw away
that segment of recorded data. And then, you see a corresponding
Event Viewer entry, for the failure that the operating system logged.

Summary: Get a new hard drive.
Replace the existing drive, before it fails.
You can use the old drive as a backup device, but knowing
it could fail at any time, and cannot be "trusted".

Paul

Woh, many thanks for this significative response. Got to read it again
as I m not exactly english thinking and poor in maths understanding !

But, well, I knew already HD Tune and what is the SMART, so i did the
readings, here is what it looks like :
http://nobody4.free.fr/ZVRAC/HD_TUNE.jpg

Setup.exe wrote:


Woh, many thanks for this significative response. Got to read it again
as I m not exactly english thinking and poor in maths understanding !

But, well, I knew already HD Tune and what is the SMART, so i did the
readings, here is what it looks like :
http://nobody4.free.fr/ZVRAC/HD_TUNE.jpg

Very interesting.

Some observations:

1) Your hard drive is too hot!

58C will ruin the hard drive.

Fit forced air cooling near the drive.

The best way to do this, is mount a fan capable of drawing cool
room air into the computer case, and have it blow directly
over the surface of the hard drive.

High temperature operation like that, will shorten the lifetime
of the hard drive motor. The lubricant inside the sealed motor,
will be forced out of the motor.

2) Reallocated sectors = 1, is not a bad number.

3) Current Pending Sectors count = 6 is more interesting.
It seems, for whatever reason, your drive may be having more problems
reading the data back later. My failing drive doesn't do that.
The thing is, since you're "loop recording", there should be many
opportunities to reduce the Current Pending Sector count, and
increase the Reallocated Sectors. But your Reallocated Sectors
is not grown significantly.

I do not know how to interpret this information, except to suggest
the high operating temperature is partially responsible. Cool off the drive.

4) Power on Hours is 14819. That's roughly 617 days of continuous
24 hour operation. Most of my drives, don't last that long here.

The customer reviews (Feedback button) for that drive, are excellent.
When it comes time to replace that hard drive with another, it will
not last nearly as long in your application.

HGST HDS722516VLAT80 Deskstar 7K250 IDE Ultra ATA100 160GB 7200 RPM

http://www.newegg.com/Product/Produc...82E16822145061

Your drive was designed some time after the IBM fiasco. IBM sold
their consumer disk division to Hitachi, after the incident described
here, and then they became HGST. And presumably, they learned from
their mistakes. I would say your 7K250 has held up well.

http://en.wikipedia.org/wiki/Deskstar

*******

Some computer cases, have an air intake fan, near the drive
bay area. This fan draws cool air from the room, and blows it
over the drive bay.

http://media.bestofmicro.com/H/I/253..._m9_intake.jpg

Mechanically, it's better if the fan is attached to the computer
case, rather than attached to the bay. Done this way, vibrations
from the fan, can interact with the disk drive.

http://media.bestofmicro.com/H/D/253...ke_m9_cage.jpg

I use an externally mounted, 120mm fan, to cool my drives. The
fan is bolted to the front of the computer, using a home-made
aluminum mounting frame. Current operating temperature of my drives
(as reported by HDTune) is 29C and 30C, and that's because it is a
summer's day. I am nowhere near 58C.

HTH,
Paul

Paul wrote:

Setup.exe wrote:

HD Tune readings
http://nobody4.free.fr/ZVRAC/HD_TUNE.jpg

Very interesting.

Some observations:

1) Your hard drive is too hot!

58C will ruin the hard drive.

According to:

http://www.hgst.com/tech/techlib.nsf/techdocs/B272B6575A7B410886256CE90058095B/$file/D7k250_ps1.pdf

The maximum *operating* temperature (that means the sustained or
constant temperature) for the device is 55 C, so 58 C is too high but
not by a lot. Remember that HDtune is stressing the device. I doubt
the drive is working as hard to occasionally dump a buffer from the
recording application to update or append to an audio file. I'm not
sure the OP simply went into HDtune to go look at the current SMART
values or if he ran their speed tests and then looked at the SMART data.

The OP may only need to include the hard disk in the fan speed control
software so the case fan speeds up when then hard disk gets too hot.
Due to hysteresis (lag in temperature readings), I'd probably set a max
temp of 50 C at which the case fan speeds up and 55 C as the warning
temperature. If the OP's computer/OS setup didn't include thermal
monitoring and fan control, Speedfan might work (but the OP would have
to know which measurements in Speedfan were for which temperature and
fan speed sensors and then rename them so he remembers later which
measurement is for what). The specs for my WDC hard disk state its
*operating* temperature maximum is 60 C, so my thresholds are 55 and 60
(to increase case fan and to alert). If a 5 C leeway isn't enough to
get the air moving in time to keep the drive's temperature below its
maximum operating temperature, it's time to blow out the dust bunnies.

However, I typically do not pile hard disks right next to each other in
the drive cage. I like to leave space between them. Even if the case
fan's speed goes up, there's not enough space between adjacent drives to
move cooling air between them. And making sure any fat/wide cables
don't block airflow is important, too. If you can't move them out of
the way, twist them so they are inline with the airflow, not against it.

3) Current Pending Sectors count = 6 is more interesting.

Only if the count doesn't go down later. This is a pending value.
Sectors that happen to get a read error may not do so later. This
operation is left pending the next write operation to those sectors to
see if they're still bad. Unless you do something to write to the same
suspect sectors, they won't get retested and then determined if bad or
good. Transient errors can make a sector look bad but when later tested
it is good. Some drives include logic to do the retest when the drive
is quiescent (i.e., offline correction), some don't. I haven't really
found good info at the drive makers' site on which do and which don't.
Just because the SMART data lists the Offline Uncorrectable count
doesn't mean the drive has that logic. Some makers include SMART values
that have no value (they're worthless, not that they have a zero value).
Just look at the C2 attribute for Temperature. Uh huh, sure, the drive
is running at 1,441,850 C (or over 2 million degrees Fahrenheit).

4) Power on Hours is 14819. That's roughly 617 days of continuous 24
hour operation. Most of my drives, don't last that long here.

That's not a continuous power-on reading. That's the total number of
hours that the device has been powered on. So the 14819 value could be
over 2 years of continuous use or over 10 years of interrupted use.
This value also may include (depends on the SMART value was implemented
by the maker) the low-power state of the device when its logic remains
powered but the platters aren't spinning.

The Power Cycle count is 123. According to definition, that's the count
of full on/off power cycles for the device. That won't include when the
device is in low-power mode (logic is powered but platters aren't
spinning). So, assuming the power save modes on the computer were NOT
configured to spin down the platters after some specified time if idle
activity addressed to the device, 14819 hours divided by 123 power
cycles is, on average, about 120 hours of constant up-time during each
power cycle, or about 5 days. If power saving settings on the computer
let the device spin down after being idle awhile, the "powered" state of
the device would be even shorter. Since the author says they run the
recording program in a constant loop so it is always recording then
there is probably no spin-down of the drive and we're back to the 5-day
average up-time. Of course, one power cycle might've had the hard disk
up only a few minutes while another power cycle had it for a year.

The other problem with the Power-On Hours count is that it can wildly
inaccurate. For some old drives, the value would wrap around (reset to
zero) or it would overflow (becomes all 1 bits) and start counting
downward or the value would advance in erratic increments.

Getting the operating temperature down below 55 C, or less, is probably
of primary concern to the OP. Then watch the *pending* sector count
(for remapping bad sector AFTER they still tested bad when they are next
rewritten) to see if it keeps going up or gradually drops or stays the
same.

VanguardLH wrote:

The maximum *operating* temperature (that means the sustained or
constant temperature) for the device is 55 C, so 58 C is too high but
not by a lot. Remember that HDtune is stressing the device.

Actually, that's not true. When you click the "Health" tab, none
of the other tests within HDTune can be running. If you start the program
and click no tabs, nothing happens. If you click the Health tab, the
SMART command is given and the statistics read out and displayed
on the screen. SMART is updated at regular intervals, so the
SMART command is issued in a slow polling mode.

If you were quick about it, you could issue the Benchmark command,
stop it half way, then click the Health tab, you might see some
elevated temperature from the Benchmark activity that just
finished. But you cannot run both activities simultaneously.

I think you can get a temperature reading, while you Benchmark (it
shows in the task bar), but the other SMART stats cannot be observed.

You can be running HDTune in parallel with other applications, in
which case you can be monitoring while stress is being applied. But
even then, there are limits. HDTune will not connect to disks which
are too busy. I observed this just yesterday, when testing two
brand new disks. They would not show up as choices in the HDTune
menu, as long as the other tests (with a separate program) were running.
If my other tests were stopped, then I could get HDTune to list
the disks in question.


3) Current Pending Sectors count = 6 is more interesting.

Only if the count doesn't go down later. This is a pending value.
Sectors that happen to get a read error may not do so later.

The OP is writing continuously to the drive. Which gives no opportunity
for read errors to show up (for Pending to climb) and gives plenty of
opportunities for Pending sectors to be resolved. It's an ideal
situation in terms of making the value go down.

On my failing drive, the Pending count has stayed at zero the whole
time, while the reallocations grow on write. Which is a bit strange.
I can read-verify my failing drive, and the Pending will not go up.
But if I do fresh writes to the drive (write 500GB of video), then
I see fresh reallocations the next time I check SMART. And the whole
thing, has made a mockery of my understanding of how automatic
reallocation works. For my drive to work the way it does, implies
the read head follows behind the write head, and can observe what
has just been written (read-after-write). And how likely is that ?

Paul