Sign in with
Sign up | Sign in
Your question

Best Hard drive for digital audio recording??????????????? - Page 2

Last response: in Home Audio
Share
Anonymous
September 13, 2005 5:15:38 PM

Archived from groups: rec.audio.pro (More info?)

"Chel van Gennip" <chel@vangennip.nl> wrote in message
news:3onqmpF6lutqU1@individual.net
> On Tue, 13 Sep 2005 10:28:19 +0200, Tim Martin wrote:

>> "Agent_C" <Agent-C-hates-spam@nyc.rr.com> spewed
>> ignorantly and arrogantly in
>> message
>> news:vl1sh11aovlrfs3to29t2eugh88pgnpqtq@4ax.com...

>>> OK, you get the award... That's the most long-winded
>>> backpeddle I've ever seen!

>> You fail to understand.

That became clear when Agent Orange claimed disks have
changed so dramatically that knowlege from the 3350 era is
now irrelevant. This is particularly ironic because some
models of 3350 had a number of fixed heads that were
assigned to a few inner cylinders. When did you see that
refinement in a PC drive? ;-)

>> Disk speed for large data
>> transfers (eg audio applications) is determined by the
>> slowest transfer rate in the chain. That would usually
>> be the rate at which data is transferred to and from the
>> surface of the disk, not how fast data is transferred to
>> and from the disk's buffer. The first will usually
>> depend on the disk size and rotation speed, the second
>> will depend on the I/O interface used.

Agreed. Fast transfers from the buffer is about electronics.
Electronics are relatively easy to make fast. Sustained data
transfer is about mechanics, and mechanics improve slowly.
In fact hard disk performance has been progressing more
slowly than CPU speed for decades.

Traditional hard drives just keep falling more and more
behind faster CPUs. The only cure at hand is stuffing more
RAM into the motherboard and RAID controllers. I notice that
even commodity motherboards are being sold with
simple-but-effective on-board RAID controllers. Both RAID
zero and RAID one have signficant practical performance
advantages.

If there's a light at the end of the tunnel that we can see,
it might be flash memory. Flash has long been a niche
product, admittedly a very large niche. But now its fully
mainstream, and the price/size situation is improving a lot
faster than it does for other more traditional forms of
memory.

> When comparing datarates it is important to understand
> that fujitsu specifies interface rates, and Maxtor often
> specifies "Sustained Transfer Rate" or media speed. The
> datarate of 60MByte/sec of the 7200RPM 250GB Maxtor sata
> drive will do for 150 channels at 96khz/32 bit floats.

Since hard drive sustained data transfer is based on
mechanics, and the mechanics of data transfer vary across
the disk, any single number for it has to be invalid unless
it's specified as a worst case. There is usually about a 3:1
or more variance across the disk.

So, you come up with big disk advantage number one - all
other things being equal an emptier drive is faster than a
fuller drive. The drive with more space will hold the same
amount of data as the smaller drive and be less full.
Therefore, the larger drive will perform better as long as
it is largely empty.

Working against this is XP's tendency to scatter data when
its added. However, XP's Dfrag program tends to move some
towards the fast parts of the disk.

> I think that will do for most digital audio recordings!
> The
> 250GB maxtor 7200 sata drive uses about half the power of
> the 73GB fujitsu 15K scsi drive.

> At 60Mbyte/sec a 73GB is filled in 20 minutes, 250GB will
> do for 70
> minutes, that might be an advantage for the users that
> need these 150 channels.

32 channels recorded at one time is enough for me! ;-)
Anonymous
September 13, 2005 6:52:51 PM

Archived from groups: rec.audio.pro (More info?)

On Tue, 13 Sep 2005 14:15:03 +0200, Arny Krueger wrote:

> So, you come up with big disk advantage number one - all other things
> being equal an emptier drive is faster than a fuller drive. The drive
> with more space will hold the same amount of data as the smaller drive
> and be less full. Therefore, the larger drive will perform better as
> long as it is largely empty.

.....

> 32 channels recorded at one time is enough for me! ;-)

So, at 32 times 96k 4-byte floats, you need 12 MByte/sec. The question is:
"Is a 60MByte/sec drive performing this task better than a 40 MByte/sec
drive?" I think not. In fact a Hitachi 4200RPM notebook drive with a media
transfer rate of 44Mbyte/sec would do the job.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com
Anonymous
September 13, 2005 6:52:52 PM

Archived from groups: rec.audio.pro (More info?)

"Chel van Gennip" <chel@vangennip.nl> wrote in message
news:3oo0d3F6r9h8U1@individual.net
> On Tue, 13 Sep 2005 14:15:03 +0200, Arny Krueger wrote:
>
>> So, you come up with big disk advantage number one - all
>> other things being equal an emptier drive is faster than
>> a fuller drive. The drive with more space will hold the
>> same amount of data as the smaller drive and be less
>> full. Therefore, the larger drive will perform better as
>> long as it is largely empty.
>
> ....
>
>> 32 channels recorded at one time is enough for me! ;-)
>
> So, at 32 times 96k 4-byte floats, you need 12 MByte/sec.

I use 44 KHz 16 bit fixed, so cut that number in half - 6
meg per second.

> The question is: "Is a 60MByte/sec drive performing this
> task better than a 40 MByte/sec drive?" I think not. In
> fact a Hitachi 4200RPM notebook drive with a media
> transfer rate of 44Mbyte/sec would do the job.

In fact I do this work while recording to a single 120 GB
7200 rpm IDE drive that is kept moderately well defragged.

It takes about 10-15 seconds to save each of the 150 meg
track files, so real-world sustained thoughput for
disk-disk file copying is something like 10-15 meg per
second.
Related resources
Anonymous
September 13, 2005 11:44:00 PM

Archived from groups: rec.audio.pro (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in message
news:ZM6dnURxpe_UXrveRVn-oA@comcast.com...

> Since hard drive sustained data transfer is based on
> mechanics, and the mechanics of data transfer vary across
> the disk, any single number for it has to be invalid unless
> it's specified as a worst case. There is usually about a 3:1
> or more variance across the disk.

That's an interesting point which has been in the back of my mind for some
time.

Usually, I set hard disks up as a single partition; but these days I'm
storing lots of stuff for which performance is not an issue. So maybe next
hard disk I'll get, I'll partition it into a "fast" part and a "slow" part.

Has anyone tried this recently (ie with >200Gb disks) and assessed the
results?

Tim
Anonymous
September 14, 2005 1:56:48 AM

Archived from groups: rec.audio.pro (More info?)

"Tim Martin" wrote ...
> Has anyone tried this recently (ie with >200Gb disks) and
> assessed the results?

Since the number of platters/heads/cylinders remains rather
constant, the laws of physics dictates that the larger the capacity
of the drive, the more data flows under the head at any given
instant. This has the effect of making higher-speed transfer
easier with larger drives.
Anonymous
September 14, 2005 12:30:00 PM

Archived from groups: rec.audio.pro (More info?)

"Tim Martin" <tim2718281@ntlworld.com> wrote in message
news:4_FVe.4612$Q%2.1606@newsfe1-win.ntli.net
> "Arny Krueger" <arnyk@hotpop.com> wrote in message
> news:ZM6dnURxpe_UXrveRVn-oA@comcast.com...

>> Since hard drive sustained data transfer is based on
>> mechanics, and the mechanics of data transfer vary across
>> the disk, any single number for it has to be invalid
>> unless it's specified as a worst case. There is usually
>> about a 3:1 or more variance across the disk.

> That's an interesting point which has been in the back of
> my mind for some time.

> Usually, I set hard disks up as a single partition; but
> these days I'm storing lots of stuff for which
> performance is not an issue. So maybe next hard disk
> I'll get, I'll partition it into a "fast" part and a
> "slow" part.

While I generally don't like partitioning, this seems like a
good application. Reserve the outer tracks for high
performance dynamic uses, and religate the inner tracks for
less-frequently used archives (that are of course backed up
someplace else).

> Has anyone tried this recently (ie with >200Gb disks) and
> assessed the results?

I've been watching this effect take place on PCs before my
very eyes ever since the days of 5 megabyte MFM full-hiegth
5.25 inch drives. Before that I watched it happen on
mainframes ever since the days of the 25 megabyte (or so)
1301 RAMAC. Except with the 1301 the space was not
formatted as bytes, it was 6 bit characters.
September 14, 2005 1:53:31 PM

Archived from groups: rec.audio.pro (More info?)

Tim Martin wrote:
> "Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
> news:vl1sh11aovlrfs3to29t2eugh88pgnpqtq@4ax.com...
>
> > OK, you get the award... That's the most long-winded backpeddle I've
> > ever seen!
>
> You fail to understand. Disk speed for large data transfers (eg audio
> applications) is determined by the slowest transfer rate in the chain. That
> would usually be the rate at which data is transferred to and from the
> surface of the disk, not how fast data is transferred to and from the disk's
> buffer. The first will usually depend on the disk size and rotation speed,
> the second will depend on the I/O interface used.

Look, all this debate about the fine points of disk storage is fine,
but I would just like to see one credible, concrete example that
supports these theories. In other words, what IDE or SATA drive in the
real world has comparable sustained data transfer rate as a 15K Fujitsu
SCSI? What's the make and model number?

The example grandpa cited didn't even come close. He culled the
universe for the one drive when they didn't publish the internal DTR,
but instead claimed a "maximum burst" of 133. Everyone knows
that's a complete ridiculous (and frankly dishonest) comparison.

A_C
Anonymous
September 14, 2005 6:34:23 PM

Archived from groups: rec.audio.pro (More info?)

"Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
news:1126716811.476347.139470@f14g2000cwb.googlegroups.com
> Tim Martin wrote:
>> "Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in
>> message
>> news:vl1sh11aovlrfs3to29t2eugh88pgnpqtq@4ax.com...
>>
>>> OK, you get the award... That's the most long-winded
>>> backpeddle I've ever seen!
>>
>> You fail to understand. Disk speed for large data
>> transfers (eg audio applications) is determined by the
>> slowest transfer rate in the chain. That would usually
>> be the rate at which data is transferred to and from the
>> surface of the disk, not how fast data is transferred to
>> and from the disk's buffer. The first will usually
>> depend on the disk size and rotation speed, the second
>> will depend on the I/O interface used.
>
> Look, all this debate about the fine points of disk
> storage is fine, but I would just like to see one
> credible, concrete example that supports these theories.
> In other words, what IDE or SATA drive in the real world
> has comparable sustained data transfer rate as a 15K
> Fujitsu SCSI? What's the make and model number?

Tell you what Agent Orange. Give us numbers for the measured
sustained DTR for your 15K Fujitsu drive, at the outer edge
and the inner edge. Benchmark = diskspeed32, most recent
version from author's web site.
September 14, 2005 11:27:33 PM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 14:34:23 -0400, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>Tell you what Agent Orange. Give us numbers for the measured
>sustained DTR for your 15K Fujitsu drive, at the outer edge
>and the inner edge. Benchmark = diskspeed32, most recent
>version from author's web site.

Tell you what Grandpa... Let's not try to manipulate the specs to
ones' own advantage. Let's let the manufacturer decide what the
specifications are. You just point me to the specific drive you have
in mind and we'll look it up; how's that?

What? You can't find a drive that rises to the challenge? You can't
find a drive that supports this statement:

---- Quoting Grandpa ----
All other things being equal, a 74 GB 15,000 rpm drive would
have about the same data transfer speed as a 350 GB 7,200
rpm drive.

IOW you should be able to approximate the kick of a 74 GB
15,000 rpm drive with a common 250 GB 7200 rpm drive, and
have the benefit of an extra 176 GB for storing data.
--- End

Gee... I wonder why?

A_C
Anonymous
September 15, 2005 12:05:48 AM

Archived from groups: rec.audio.pro (More info?)

"Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
news:1126716811.476347.139470@f14g2000cwb.googlegroups.com...

> In other words, what IDE or SATA drive in the
> real world has comparable sustained data transfer rate as a 15K Fujitsu
> SCSI? What's the make and model number?

I know Seagate quote similar sustained data rates for the Barracuda SATA
7200rpm 250GB ST3250823A (65 millions bytes per second) and the Cheetah
UltraSCSI 320 15000rpm 73.4GB ST372245 (58 to 96 million bytes per second).
Those figures indicate the Seagate disks have a single read head active at a
time.

I'd expect the Fujitsu to have a similar sustained data rate range as the
Seagate SCSI disk. (Obviously the Seagate SATA disk has a range of transfer
rates too, but they are quoting the performance figure in a different way.)

Tim
Anonymous
September 15, 2005 12:05:49 AM

Archived from groups: rec.audio.pro (More info?)

"Tim Martin" <tim2718281@ntlworld.com> wrote in message
news:wo%Ve.9195$zw1.5792@newsfe2-gui.ntli.net
> "Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
> news:1126716811.476347.139470@f14g2000cwb.googlegroups.com...
>
>> In other words, what IDE or SATA drive in the
>> real world has comparable sustained data transfer rate
>> as a 15K Fujitsu SCSI? What's the make and model number?
>
> I know Seagate quote similar sustained data rates for the
> Barracuda SATA 7200rpm 250GB ST3250823A (65 millions
> bytes per second) and the Cheetah UltraSCSI 320 15000rpm
> 73.4GB ST372245 (58 to 96 million bytes per second).
> Those figures indicate the Seagate disks have a single
> read head active at a time.

I just checked my Barracuda SATA 7200rpm 160GB ST3160023ASA
with diskspeed32.exe and got 58 meg/sec for the outer
tracks.
September 15, 2005 12:05:49 AM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 20:05:48 GMT, "Tim Martin"
<tim2718281@ntlworld.com> wrote:

>I'd expect the Fujitsu to have a similar sustained data rate range as the
>Seagate SCSI disk.

Not really.
http://www.fcpa.fujitsu.com/products/hard-drives/mau-31...

(MAU3073):
Data transfer rate To/from media 147 MB/s
To/from host SCSI: 320 MB/s, FC: 2 Gb/s
Anonymous
September 15, 2005 1:21:07 AM

Archived from groups: rec.audio.pro (More info?)

"Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
news:cachi1pb9mrcm565g49pvhe9pkos43v9f2@4ax.com
> On Wed, 14 Sep 2005 14:34:23 -0400, "Arny Krueger"
> <arnyk@hotpop.com> wrote:
>
>> Tell you what Agent Orange. Give us numbers for the
>> measured sustained DTR for your 15K Fujitsu drive, at
>> the outer edge and the inner edge. Benchmark =
>> diskspeed32, most recent version from author's web site.
>
> Tell you what Grandpa...

4 times, thank you.

>Let's not try to manipulate the
> specs to ones' own advantage.

No need.

> Let's let the manufacturer decide what the specifications
> are.

You obviously think that will give you an advantage.

>You just point me to
> the specific drive you have in mind and we'll look it up;
> how's that?

The largest SATA drive I can find specs for is the WD2500JS
and WD2500KS

Here are the specifications for the WD 250GB Second
Generation Serial ATA drive (model WD2500JS, WD2500KS) from
the WD web site:

Data Transfer Rate (maximum)

- Buffer to Host 300 MB/Sec
- Buffer to Disk 748 Mbits/s max
Anonymous
September 15, 2005 1:22:07 AM

Archived from groups: rec.audio.pro (More info?)

"Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
news:46dhi1thrvhcn0c9s8n1iqqs6hljer43vm@4ax.com
> On Wed, 14 Sep 2005 20:05:48 GMT, "Tim Martin"
> <tim2718281@ntlworld.com> wrote:
>
>> I'd expect the Fujitsu to have a similar sustained data
>> rate range as the Seagate SCSI disk.
>
> Not really.
> http://www.fcpa.fujitsu.com/products/hard-drives/mau-31...
>
> (MAU3073):
> Data transfer rate To/from media 147 MB/s
> To/from host SCSI: 320 MB/s, FC: 2 Gb/s

Here are the specifications for the WD 250GB Second
Generation Serial ATA drive (model WD2500JS, WD2500KS) from
the WD web site:

Data Transfer Rate (maximum)

- Buffer to Host 300 MB/Sec
- Buffer to Disk 748 Mbits/s max
Anonymous
September 15, 2005 2:19:39 AM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 22:05:48 +0200, Tim Martin wrote:

> I know Seagate quote similar sustained data rates for the Barracuda SATA
> 7200rpm 250GB ST3250823A (65 millions bytes per second) and the Cheetah
> UltraSCSI 320 15000rpm 73.4GB ST372245 (58 to 96 million bytes per
> second).

So if you only use the outer 73 GB of the 250 GB 7200rpm sata drive you
outperform the 15K scsi drive.

Those 15K drives are good for e.g. DB applications: many short writes that
are time critical. There the rotational delay is important. For sustained
audio streams there is hardly any benefit.

--
Chel van Gennip
Visit Serg van Gennip's site http://www.serg.vangennip.com
Anonymous
September 15, 2005 2:38:34 AM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 08:30:00 -0400, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>While I generally don't like partitioning, this seems like a
>good application. Reserve the outer tracks for high
>performance dynamic uses, and religate the inner tracks for
>less-frequently used archives (that are of course backed up
>someplace else).

Cool. Are the outer tracks an earlier letter or a later?
(D: vs. E:) 

Thanks, as always,

Chris Hornbeck
Anonymous
September 15, 2005 2:38:35 AM

Archived from groups: rec.audio.pro (More info?)

"Chris Hornbeck" <chrishornbeckremovethis@att.net> wrote in
message news:ae9hi1t6bbuhdclbpdsdb8gtififndsjke@4ax.com
> On Wed, 14 Sep 2005 08:30:00 -0400, "Arny Krueger"
> <arnyk@hotpop.com> wrote:
>
>> While I generally don't like partitioning, this seems
>> like a good application. Reserve the outer tracks for
>> high performance dynamic uses, and religate the inner
>> tracks for less-frequently used archives (that are of
>> course backed up someplace else).
>
> Cool. Are the outer tracks an earlier letter or a later?
> (D: vs. E:) 

Drive letter assignments in XP are arbitrary. Actually most
of them were arbitrary in the DOS OS's, but the changes
weren't so easy to make permanent. At any rate in XP, its
easy to you can have drive letter assignments as you like
them.
Anonymous
September 15, 2005 5:03:54 AM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 20:47:15 -0400, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>>> While I generally don't like partitioning, this seems
>>> like a good application. Reserve the outer tracks for
>>> high performance dynamic uses, and religate the inner
>>> tracks for less-frequently used archives (that are of
>>> course backed up someplace else).
>>
>> Cool. Are the outer tracks an earlier letter or a later?
>> (D: vs. E:) 
>
>Drive letter assignments in XP are arbitrary. Actually most
>of them were arbitrary in the DOS OS's, but the changes
>weren't so easy to make permanent. At any rate in XP, its
>easy to you can have drive letter assignments as you like
>them.

Remembering that you're responding to a real idiot,
could you perhaps hit the highpoints of how that
idiot would go about reserving outer tracks to
one partition, and inner tracks to another?

Assuming that it can be done, as implied above. And
without Partition Magic, etc. During the initial
FDISKing perhaps? I'm still in FAT32/ Win98SE here
at the shack, if that matters.

Much thanks,

Chris Hornbeck
Anonymous
September 15, 2005 5:03:55 AM

Archived from groups: rec.audio.pro (More info?)

"Chris Hornbeck" <chrishornbeckremovethis@att.net> wrote in
message news:D lhhi19bs2f6cq6ljjubrljkd6tvb9rns5@4ax.com
> On Wed, 14 Sep 2005 20:47:15 -0400, "Arny Krueger"
> <arnyk@hotpop.com> wrote:
>
>>>> While I generally don't like partitioning, this seems
>>>> like a good application. Reserve the outer tracks for
>>>> high performance dynamic uses, and religate the inner
>>>> tracks for less-frequently used archives (that are of
>>>> course backed up someplace else).
>>>
>>> Cool. Are the outer tracks an earlier letter or a later?
>>> (D: vs. E:) 
>>
>> Drive letter assignments in XP are arbitrary. Actually
>> most of them were arbitrary in the DOS OS's, but the
>> changes weren't so easy to make permanent. At any rate
>> in XP, its easy to you can have drive letter assignments
>> as you like them.
>
> Remembering that you're responding to a real idiot,
> could you perhaps hit the highpoints of how that
> idiot would go about reserving outer tracks to
> one partition, and inner tracks to another?

It depends on your partitioning software.

However, the default is to assign space from the outside
tracks, inward.

So if you are partitioning a drive with software that
doesn't let you specify where the partition is, the default
is that the first partition is on the outside, and sucessive
partitions are allocated from the outside going in.



> Assuming that it can be done, as implied above. And
> without Partition Magic, etc. During the initial
> FDISKing perhaps? I'm still in FAT32/ Win98SE here
> at the shack, if that matters.

My recollection is that FDISK is one of those pieces of
software where you have no choice, other than that the
partitions are allocated from the outside, in.
Anonymous
September 15, 2005 5:48:35 AM

Archived from groups: rec.audio.pro (More info?)

On Wed, 14 Sep 2005 21:24:47 -0400, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>However, the default is to assign space from the outside
>tracks, inward.
>
>So if you are partitioning a drive with software that
>doesn't let you specify where the partition is, the default
>is that the first partition is on the outside, and sucessive
>partitions are allocated from the outside going in.

>My recollection is that FDISK is one of those pieces of
>software where you have no choice, other than that the
>partitions are allocated from the outside, in.

Thanks much. Even my (admittedly ancient) version of
Partition Magic doesn't really operate in terms of
"inside" and "outside". And FDISK is the black hole
of all knowledge.

I suppose that I could have partitioned a fresh drive,
run some freeware data-squeezing test program that I
wouldn't necessarily trust, and found out (some) answer
for myself.

But in areas where I know enough to be dangerous, I
also know enough to ask somebody I trust. For this
field especially you're numero uno.

This newsgroup is a great collection of such folks.
Much thanks to all,

Chris Hornbeck
Anonymous
September 15, 2005 1:31:36 PM

Archived from groups: rec.audio.pro (More info?)

"Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
news:46dhi1thrvhcn0c9s8n1iqqs6hljer43vm@4ax.com...

>
http://www.fcpa.fujitsu.com/products/hard-drives/mau-31...
>
> (MAU3073):
> Data transfer rate To/from media 147 MB/s

OK, that one's about 25% faster than the 15k rpm Fujitsu whose speeds I was
looking at (MAS3735, max speed to/from media 118.2MB/sec).

To get the sustained data rate, you need to multiply the data transfer rate
to and from the medium by the ratio of data bits per track to unformatted
bits per track. Fujitsu don't give that figure, but it will be a number in
the region of 0.5 to 0.7.

Tim
Anonymous
September 15, 2005 1:31:37 PM

Archived from groups: rec.audio.pro (More info?)

"Tim Martin" <tim2718281@ntlworld.com> wrote in message
news:YbbWe.6516$st1.1960@newsfe3-gui.ntli.net

> "Agent_C" <Agent-C-hates-spam@nyc.rr.com> wrote in message
> news:46dhi1thrvhcn0c9s8n1iqqs6hljer43vm@4ax.com...


> http://www.fcpa.fujitsu.com/products/hard-drives/mau-31...

>> (MAU3073):
>> Data transfer rate To/from media 147 MB/s

Agent Orange has a way to go to come close to the following
specs for WD's ATA-2 drives:

Here are the specifications for the WD 250GB Second
Generation Serial ATA drive (model WD2500JS, WD2500KS) from
the WD web site:

Data Transfer Rate (maximum)

Buffer to Host 300 MB/Sec
Buffer to Disk 748 Mbits/s max

> OK, that one's about 25% faster than the 15k rpm Fujitsu
> whose speeds I was looking at (MAS3735, max speed to/from
> media 118.2MB/sec).

> To get the sustained data rate, you need to multiply the
> data transfer rate to and from the medium by the ratio of
> data bits per track to unformatted bits per track.
> Fujitsu don't give that figure, but it will be a number
> in the region of 0.5 to 0.7.

Along the way it was revealed that at least some of these
fast-spinning drives have only 2.5 inch discs in 3.5"
housings. If you think about it, from a sustained throughput
standpoint, this is just playing with numbers. It reduces
the advantage of the high rotational speed to just latency.
Latency is very important for random access, but for
sequential I/O its not that important.
Anonymous
September 15, 2005 1:31:38 PM

Archived from groups: rec.audio.pro (More info?)

I'm coming in late on this one, but has anyone pointed out that, regardless
of which drive you own, it should be regularly defragmented? Like maybe
after each recording session?
Anonymous
September 15, 2005 1:31:39 PM

Archived from groups: rec.audio.pro (More info?)

"William Sommerwerck" <gizzledgeezer@comcast.net> wrote in
message news:jK6dnXAgxMOawrTeRVn-sw@comcast.com

> I'm coming in late on this one, but has anyone pointed
> out that, regardless of which drive you own, it should be
> regularly defragmented? Like maybe after each recording
> session?

That can be inconvenient. The alternative is to build your
DAW with an overbuilt I/O subsystem, which I've found to be
very easy to do, at least up to 24 concurrent tracks.
Anonymous
September 22, 2005 4:14:03 PM

Archived from groups: rec.audio.pro (More info?)

On Thu, 15 Sep 2005 04:44:47 -0700, "William Sommerwerck"
<gizzledgeezer@comcast.net> wrote:

>I'm coming in late on this one, but has anyone pointed out that, regardless
>of which drive you own, it should be regularly defragmented? Like maybe
>after each recording session?

And to point out that it can make surprisingly little difference.

Consider a multi-track recorder laying ,say, 8 tracks. They are
stored as 8 separate wav files. Where will they be laid on the disk
surface? Where will they be after defragmentation? When you play
those 8 tracks and simultaneously record another 8, what will the hard
drive head have to do? Does your defrag program know that a.wav and
b.wav belong to one song and should be kept together, whereas c.wav
and d.wav belong to another project?
Anonymous
September 22, 2005 4:14:04 PM

Archived from groups: rec.audio.pro (More info?)

"Laurence Payne" <lpayne1NOSPAM@dsl.pipexSPAMTRAP.com>
wrote in message
news:f645j1t3j24hegq4jt7a9jl1ehgts11ei8@4ax.com
> On Thu, 15 Sep 2005 04:44:47 -0700, "William Sommerwerck"
> <gizzledgeezer@comcast.net> wrote:
>
>> I'm coming in late on this one, but has anyone pointed
>> out that, regardless of which drive you own, it should
>> be regularly defragmented? Like maybe after each
>> recording session?
>
> And to point out that it can make surprisingly little
> difference.
>
> Consider a multi-track recorder laying ,say, 8 tracks.
> They are stored as 8 separate wav files. Where will they
> be laid on the disk surface? Where will they be after
> defragmentation? When you play those 8 tracks and
> simultaneously record another 8, what will the hard drive
> head have to do?

The point here being that at record time the files are
written out in what from the outside look like fragmented
blocks. The data blocks for the audio tracks will be
interleaved. If you play them back, to minimize seeking,
you'd like that interleaving be preserved.

Ironically, sometimes a disk can be so fragmented that
defragging will make a mulitrack session play back better.

A good audio computer should have enough reserve I/O power
that it will work right, fragmented or not.

> Does your defrag program know that
> a.wav and b.wav belong to one song and should be kept
> together, whereas c.wav and d.wav belong to another
> project?

Yes, any reasonable defrag program will consolidate the
track files into individual groups of contigious blocks,
which will *increase* the amount of seeking required to play
them back as compared to interleaving, which looks from the
outside to be fragmentation.
Anonymous
September 22, 2005 4:31:09 PM

Archived from groups: rec.audio.pro (More info?)

Laurence Payne wrote:

> On Thu, 15 Sep 2005 04:44:47 -0700, "William Sommerwerck"
> <gizzledgeezer@comcast.net> wrote:
>
> >I'm coming in late on this one, but has anyone pointed out that, regardless
> >of which drive you own, it should be regularly defragmented? Like maybe
> >after each recording session?
>
> And to point out that it can make surprisingly little difference.
>
> Consider a multi-track recorder laying ,say, 8 tracks. They are
> stored as 8 separate wav files. Where will they be laid on the disk
> surface? Where will they be after defragmentation? When you play
> those 8 tracks and simultaneously record another 8, what will the hard
> drive head have to do? Does your defrag program know that a.wav and
> b.wav belong to one song and should be kept together, whereas c.wav
> and d.wav belong to another project?

Hardly the issue. File fragmentation is about a single file ending up in many
bits all over the place requiring loads of head seeks to continually reposition.

Graham.
Anonymous
September 23, 2005 1:18:39 PM

Archived from groups: rec.audio.pro (More info?)

"Laurence Payne" <lpayne1NOSPAM@dsl.pipexSPAMTRAP.com> wrote in message
news:f645j1t3j24hegq4jt7a9jl1ehgts11ei8@4ax.com...
> On Thu, 15 Sep 2005 04:44:47 -0700, "William Sommerwerck"
> <gizzledgeezer@comcast.net> wrote:
>
>>I'm coming in late on this one, but has anyone pointed out that,
>>regardless
>>of which drive you own, it should be regularly defragmented? Like maybe
>>after each recording session?
>
> And to point out that it can make surprisingly little difference.
>
> Consider a multi-track recorder laying ,say, 8 tracks. They are
> stored as 8 separate wav files. Where will they be laid on the disk
> surface? Where will they be after defragmentation?

They will be at the same place as when 'laid'. Fragmentation does not occur
after writing.

Until you defrag...

geoff
      • 1
      • 2 / 2
!