The case for recording audio at 24-bit, 96kHz is being ever more strongly promoted, but operating at high resolution has an impact on the performance of audio-recording computers, hard drives, and thus sequencer track counts. We give you some solid figures...

---

Mike Watkinson

As a result of the track counts achieved in April's article on testing FireWire hard drives in a range of modern Macs (see www.soundonsound.com/ sos/apr02/ articles/firewire2.asp), I was encouraged to push the envelope a little further. I showed in that article that several of the drives I had on test were capable of performance far exceeding the requirements of most projects at the standard resolution and sample rate for CD-quality audio (16-bit, 44.1kHz). The arrival at my studio of MOTU's 896, which I reviewed in the July issue of SOS, provided the ideal excuse to see what happens to these track counts if the quality is increased to 24-bit and 96kHz.

Ever since digital recording's infancy, debate has been raging about its merits. I don't want to reopen old wounds here; suffice it to say that 24/96 exists to satisfy the ever-increasing thirst for absolute sonic quality, and that as technology improves, so bit depth and sample rate will increase. Both 32-bit and 192kHz are already in use, although not necessarily at the same time.

When the cognoscenti are discussing 24/96, their general understanding seems to be that, even though file size is increased by a factor of 3 (moving from 16- to 24-bit is a factor of 1.5, then you have to double that when you double the sample rate), the overhead required to process such files is more like four times that demanded by 16/44.1 data. The purpose of this article is to see the actual effect of working at 24/96 on achievable track count.

The third external drive used this month — Glyph's M-Project.

Hardware On Test

Three external FireWire hard drives remained on loan for these tests. LaCie (who supplied the StudioDrive and PocketDrive) and Glyph (who supplied the M-Project) are both well aware of the importance of 24/96 and were keen to see how well their drives performed.

MOTU's DP3 running 64 continuous tracks.

Two Macs were used, the new-style iMac which I recently reviewed for SOS (see www.soundonsound.com/sos/May02/ articles/imac800.asp) and my own 2001-vintage iBook, so both their internal drives were also tested. These two computers were chosen specifically because FireWire is their only expansion option as far as serious audio work is concerned (please see the Test Spec side panel for more detailed information). A desktop Power Mac would, of course, have a range of PCI-based solutions for audio interfacing, and the further option of SCSI storage if required.

MOTU's DP3 software was used far more extensively in these tests, following its excellent showing in April's article. Emagic were able to respond to DP3's challenge with the new version 5.0 of Logic Audio Platinum, although in order to cross-reference back to previous results, I also carried out all my tests with version 4.8.1.

Finally, although it wasn't strictly on test here, I must thank MOTU's UK distributor Musictrack for lending me the first production 896 interface to reach the UK.

The Tests

To provide parity with previous results, I created two basic types of test, the first based on long continuous audio files, and the second based on short repeating files. Each test was recreated as closely as possible in both of the test sequencers.

Emagic's Logic v5.0 running 64 continuous tracks.

• LONG FILES

Firstly, I created a 16/44.1 mono audio file approximately one minute long and converted it to 24/96 using the Convert Sample Rate and Convert Sample Format functions from the mini-menu on the Soundbites window in DP3. In Logic Audio I then imported and dragged this file to track 1 of the Arrange window, and made a copy of it on each of the 63 other tracks in the song (by holding down the Alt/Option key and dragging the mouse). Finally, I converted the resulting audio regions to audio files using the Convert Regions To Individual Audio Files command from the Audio menu of the Arrange window.

To recreate the song in DP3, I dragged the 64 audio files (as created by Logic) en masse onto DP3's Soundbites window, then dragged each in turn from here to its own track on the Tracks window. Both versions of the song had the audio files starting at Bar 3, to give the program buffers a chance to load huge amounts of data before being required to play it — any project with a high track count will benefit from a stretch of silence before the first audio event.

• SHORT FILES

The short audio files test was created in Logic as before (see April issue), by copying a single short audio file (one 16th of a bar at 120bpm), which I had previously converted to 24/96 in DP3, until there were 16 instances of it in a bar. I then arranged eight of these bars per track, making 128 instances per track. To ensure that Logic created a separate audio file for all 128 instances, I used the Convert Regions To Individual Regions function, followed by Convert Regions To Individual Audio Files. I then copied this track 31 times (one copy per track) making a total of 4096 files (ie. 32 x 128) for the eight-bar song!

Logic v5.0 running 32 tracks of short audio files.

Recreating this song in DP3 proved something of a challenge. Probably because there is no practical reason why you would ever want to make 4096 copies of the same audio file (you would just make instances which refer to the original) DP3 provides no routine for replacing regions with newly created audio files which sound the same as the instance they are replacing. So I had to find another way.

Using the fact that Sound Designer II files contain region information which is 'timestamped' (that is, the audio regions contain positional information based on their position on the timeline of the song), the tracks of the Logic short files project were exported as SDII files, a track at a time, each track to its own folder. In DP3, I then dragged the contents of a track folder onto the corresponding track on the Sequence window, and called up the Move To Original Time Stamp function from the Audio menu. As long as the sample rates in both projects were set to 96kHz, and the frame rates were also matched, the audio files then assumed identical positions in time to those they occupied in Logic, as shown in the screenshots (left and right).

Once the two DP3 songs (one each for the long and short tests) had been created, one final operation was necessary to make these into fully independent projects. I selected the Save A Copy As... function from the File menu with the Duplicate Audio Data box ticked, which saves a new copy of the song with fresh independent audio files into a new project folder. Job done!

Test Settings

In order to achieve fair comparisons between drives and systems, I had to ensure that several key parameters were set equally in each case. Consequently, unless otherwise stated, the Mac OS disk cache was left set to default (32 times physical RAM). All extensions for Mac OS 9.2.2 were left on and no other software apart from the test applications was installed. In Logic Audio v4.8.1 (and v5.0) the Larger Process Buffer and Larger Disk Buffer were turned off and on respectively. In DP3, the Samples Per Buffer option was set to 256kB, with all other settings left at default. In the Automation Setup dialogue (found under DP3's Basics menu), I ticked the Mute Frees System Resources option. This means that only Play Enabled tracks are buffered and processed.

I initialised all external drives with Mac OS (the Mac OS disk driver being used in all cases), and used Symantec's Norton Utilities to prepare the internal drives prior to testing — more on this in the box on the final page.

Results

Comparing the test results for Logic Audio in Tables 1 and 4 overleaf, two conclusions can be drawn. Firstly, that using 24/96 audio does reduce the track count, but by a factor less than the expected three. Secondly, the change to 24/96 has little impact on the ability of the slower drives (LaCie's PocketDrive and the internal drives) to deliver short audio files, suggesting that seek time is the limiting factor in this case.

DP3 running 32 tracks of short audio files.

Looking at DP3's results in the same tables, the outstanding figures achieved with continuous 16/44 files on the PocketDrive and internal drive are not extrapolated as the drives get faster (with the disk driver samples per buffer set at 256 — see Table 4); nor is there a corresponding increase in ability to play back 24/96 audio. Strangely, playing back multiple short files caused DP3 problems in every test. Although the 'Disk Too Slow' error message did not appear, the playback suffered from dropouts, which increased with the number of tracks. This situation did not change significantly when the Samples Per Buffer setting was raised to its maximum. It was therefore very difficult to put precise numbers to the track count in this case, and hence the figures should not be taken as accurate.

Communication with MOTU and their UK distributors Musictrack as to why this should be reinforced my hunch that MOTU have optimised their software for the playback of continuous audio, in the classic (tape-based) recording style. Here is an edited version of their response: "The SOS 'short file' test is obviously not a real-world situation. DP is much better tuned for a similar, but different situation: lots of short 'slivers' of audio that are soundbites from larger parent audio files. REX files (from Propellerhead's Recycle loop-editing program) are a perfect example of this. A REX file is typically two to four bars long. But when you import it into DP, you get dozens — sometimes even hundreds — of soundbite 'slivers' from that two-to-four-bar file. Our engineers seem certain that DP3 performs much better in this more real-world scenario because the MAS engine is tuned for this." The supposition, then, is that DP3 is quite happy when a larger parent audio file is referred to by multiple short regions, such as a series of 16th notes (as is the case with REX files), but is not so keen if each region (or 'soundbite' in MOTU-speak) points to a separate audio file. MOTU technical support staff suggested I change the disk cache size, but as Table 2 (right) shows, this actually had very little influence on the drives' performances.

Although the short file tests were inconclusive, the long file tests on the slower drives saw DP3 running significantly more tracks than Logic, a disparity which was not carried over to the faster drives. In my opinion, this suggests that the influence of sustained data transfer rate is outweighed by the fact that DP3's audio engine is specifically geared to the demands of continuous files. Results from April's article went some way to proving that the ASIO driver for MOTU FireWire devices is just as efficient in terms of track count as the Mac AV, so it is not possible to claim this driver as the culprit for Logic's poorer performance in this test.

Table 3 (above) shows the increased role of the processor in handling 24/96 audio files, and underlines the results in Table 2. Although no plug-ins were, um, plugged in, the faster G4 800MHz processor of the iMac helped to increase the data throughput possible from each drive.

Table 4 (above) shows results for 16-bit 44.1kHz files, all other parameters remaining equal. In DP3 the first error message which appeared in some instances was not 'Disk Too Slow' but 'Sustained CPU Use Too High', with the option given of changing the number of samples per buffer handled by the audio driver from the default to a higher number. I chose 1024 (the highest available) and re-tested, getting the figures seen in the table. With this setting, the DP3 results on the slower drives are bettered by their faster rivals (unlike the results with the samples per buffer set at 256), and as a group are an average of 20 tracks per test better than the results from Logic. Choosing a value for Samples Per Buffer in DP3 has a similar effect on track count to changing Larger Process Buffer or Larger Disk Buffer settings in Logic. Seeing DP3 outperform Logic in this test underlines my earlier supposition about the way the respective sequencers' audio engines are tuned. I wouldn't mind betting that spare processing power is hard to come by when DP3 is playing back 82 tracks!

Table 5 (opposite, above) shows that despite its increased functionality, the 896 interface imposes the same load on the FireWire buss as its sister, the 828, where track counts are concerned. Interestingly, though, both the 828 and 896 do affect the track count in a negative way when used as the audio device in DP3, when compared to performance with the Mac AV driver and internal hardware. In April's article, I made reference to a DP3 track count of 84 continuous 16/44 files on the LaCie Pocket drive, when connected to the iBook. This was achieved using Mac AV as the audio device. With an 828/896 selected as the audio device, this reduces to 65 at 256 samples per buffer (and 74 at 1024 samples per buffer). While Logic can't match DP3 in this one test, April's figures do show that Logic's track counts weren't affected by choice of audio device.

Table 6 (right) bears out the evidence of Table 5. In addition, it shows that handling 24/96 files does indeed tax the processor quite heavily, and that this has a more significant effect with slower processors. This last test was carried out away from my usual Mac on a dual-processor 800MHz machine without Logic, hence the lack of readings for that program, although I did cross-reference with my iBook.

Using Norton Utilities With Dual-Boot Macs     How to defragment a Mac running System 9 when using a version of Symantec's Norton Utilities prior to v7, as explained on Symantec's web site. The dual-boot system disk in the iMac and iBook poses several problems for audio use. I attempted to defragment the drives using Speed Disk from my trusty copy of Symantec's Norton Utilites for the Mac v5.02, but on the dual-boot Macs, you can no longer start up from the Norton disc. Nevertheless, there is a way to check the disk and defragment, as detailed at http://service2.symantec.com/support/ num.nsf/pfdocs/2000082914335711). I was surprised to see Speed Disk report 'Severe' fragmentation on a drive which had been freshly prepared using the Restore discs supplied with the Mac! Symantec's technical support explained that these discs are likely to be images of a master disk that must itself be severely fragmented. Disk Doctor also warned of major errors which, if you let NUM v5.02 fix them, may cause operational problems. Symantec assured me that Mac OS X is to blame, and that the new version 7.0 of NUM is Mac OS X-compliant. They rushed me a press copy the day before the deadline for this article, and I can happily report that it coped with all the above problems without reporting major faults, and also appeared to carry out most of its routines faster than with previous versions. NUM continues to be an invaluable tool for maintaining healthy system disks, until Apple builds these tools into its OS (whenever that might be!).

Conclusions

Although some of the above results are inconclusive, especially when you ask DP3 to play back many short files, what is certain is that MOTU's sequencer loves 'continuous' tracks, good results being achieved on all test drives at 24/96. Logic turns in a more stable all-round performance, seeing better results from the large, fast drives when playing back continuous audio.

Looking at the drives themselves, both the LaCie StudioDrive and Glyph M-Project give good performances with all software, and surprisingly, the LaCie PocketDrive performs almost as well as its faster sibling when using DP3.

What these results also illustrate is that a faster computer will help enormously if 24/96 is your goal. As well as improving the available performance of your chosen drive, it will also allow a decent number of plug-ins to be used at the same time.

In summary, if you wish to work at 24/96 on a laptop, FireWire drives offer a good solution for projects with a small-to-medium track count. Even the smallest drive here could easily play back a 10.2 surround mix at this resolution with no problem!

Test Spec     Apple iBook 600 CPU: G3 600MHz. Buss: 100MHz. RAM: 384Mb. Mac OS 9.2.2. Apple iMac 800 Superdrive CPU: G4 800MHz. Buss: 100MHz. RAM: 256Mb. Mac OS 9.2.2.

Glyph M-Project LaCie PocketDrive LaCie StudioDrive Internal drive Logic v4.8.1 long 27 18 27 22 Logic v5.0 long 26 16 27 22 DP3 long 26 24 26 29 Logic v4.8.1 short 16 13 15 18 Logic v5.0 short 16 13 14 16 DP3 short • 11 10 11 11 • Audio drops out — results unreliable. Table 1: iBook track counts with 24/96 mono files, and a default disk cache.

Glyph M-Project LaCie PocketDrive LaCie StudioDrive Internal drive Logic long 26 16 26 21 Logic short 15 14 14 17 DP3 long 29 24 25 29 DP3 short • 11 12 10 11 • Audio drops out — results unreliable. Table 2: iBook track counts with 24/96 mono files, and a 512kB disk cache.

Glyph M-Project LaCie PocketDrive LaCie StudioDrive Internal drive Logic v4.8.1 long 33 21 32 29 Logic v4.8.1 short 21 17 16 22 DP3 long 32 31 31 36 DP3 short • 12 11 12 12 Logic v5.0 long — — — 29 Logic v5.0 short — — — 22 • Audio drops out — results unreliable. Table 3: iMac track counts with 24/96 mono files, and a default disk cache.

Glyph M-Project LaCie PocketDrive LaCie StudioDrive Internal drive Logic v4.8.1 long mono 64 47 64 50 Logic v5.0 long mono 64 48 66 49 DP3 long mono (256 samples per buffer) 68 65 66 77 DP3 long mono (1024 samples per buffer) 82 74 78 80 Logic v4.8.1 short mono 25 12 23 18 Logic v5.0 short mono 24 12 22 15 DP3 short mono • 12 10 11 11 • Audio drops out — results unreliable. Table 4: iBook track counts with 16/44.1 mono files, and a default disk cache.

896/16/44.1 828/16/44.1 StudioDrive long mono 64 64 PocketDrive long Mono 47 47 StudioDrive short Mono 23 23 PocketDrive short Mono 13 12 Table 5: MOTU 896 versus 828 buss load — effect on track count (Logic v5.0 on iBook).

PlatinumVerbs in Logic eVerbs in DP3 896 at 24/96 on iBook 3 5 896 at 16/44.1 on iBook 10 14 828 at 16/44.1 on iBook 10 13 1296 at 24/96 on Dual 800 — 22 1296 at 16/44.1 on Dual 800 — 35 Table 6: 24/96 vs. 16/44 — effect on processor loading (MOTU 828/896/1296 on iBook and Dual 800).

 

Home | Search | News | Current Issue | Digital Editions | Articles | Forum | Subscribe | Shop | Readers Ads

Advertise | Information | Links | Privacy Policy | Support