Hi Tom,

The converse argument for future proofing is that video and pro audio is
all standardized on 48kHz. Quite a lot of people believe that audio with
video is more likely the standard for the future than audio alone. If
you wanted to repurpose audio to sync with video, choosing a 44.1kHz
base standard would not be the best choice. Considering that SACD and
DVD-A are generally considered dead formats, whereas, Blu-ray is still
hanging on, one could argue that hi-res and media based audio is more
likely to succeed on a video format. Or look at how many podcasts have
moved from audio only to audio with video and almost all portable mp3
type players have the ability to show video. Of coarse this is all
conjecture, but those are the types of arguments made. Also, many find
the current resampling methods available to be so transparent between
96kHz and 44.1kHz that it isn't a problem for down-sampled listening and
if you want to listen to the highest fidelity version available, you
would playback the hi-res source and down-sampling wouldn't even come
into play.

Peter

>>> Tom Fine <[log in to unmask]> 11/19/09 8:06 AM >>>
PS -- I'm a big advocate of standardizing on 88.2/24 as the archival
transfer format due to the very
simple computer math of down-sampling the long-established and heavily
entrenched CD standard for
playback and general-use copies. The Grammy Foundation demands 96/24 as
a minimum, so most grant
recipients must adhere to this since most grant givers seem to adopt
Grammy Foundation standards. I
don't think it's a huge issue, but making something future proof, it
seems to me, includes making
conversion to common-use formats as simple as possible. I'm not saying
computing is likely to take a
step back to where it's "hard math" to down-sample from 96 to 44.1, but
it's not outside of all
possibilities, so why create a small risk for no reason. Is there a
science-based argument where 96
vs 88.1 makes any difference in the audible frequencies?

-- Tom Fine

----- Original Message -----
From: "Tom Fine" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, November 19, 2009 7:55 AM
Subject: Re: [ARSCLIST] Sound Forge issues


> Hi Guys:
>
> I've been using SoundForge since V4 (pre-Sony). Now using V9 in the
studio. In my Windows XP Pro
> systems, 2gig seems to be the limit, not time of audio. As a rule,
when I'm transferring in 96/24
> or 88.1/24, which is most of the time, I have to keep file-running
time to 58 minutes for 2
> channels, just under 2 hours for mono.
>
> This formula seems to work:
>
> ----------------------------------------
> size = sample rate * number of channels * (bits per sample /8) * time
in seconds.
>
> So a 44.1 hHz, stereo 16 bit wav file lasting 60 seconds should be :
>
> Size = (44.1 * 2 * (16/8) * 60) / 1024 [the division by 1024 is to get
megabytes]
> Size = 10,3359 MB
> ------------------------------------------
>
> But I am not a mathematics person by any stretch!
>
> Using this formula, 58 minutes of 96/24 2-channel creates 1.9575 gig
of data. Soundforge file
> headers and metadata stuff don't take up more than a few bits, so this
is a safe outer limit, in
> my experience.
>
> Using 88.2/24, you can go just over 1 hour within the file size.
>
> -- Tom Fine
>
> ----- Original Message -----
> From: "Peter Alyea" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Thursday, November 19, 2009 7:29 AM
> Subject: Re: [ARSCLIST] Sound Forge issues
>
>
>> Hi Steve,
>>
>> I tried to save data in Sound Forge v10 to the WAV format that would
>> result in a file that was larger than 2GB and the warning dialog box
>> popped up telling me that I was trying to save an illegal file size.
>> Unless you have uncovered an unusual bug in Sound Forge, I would
guess
>> that the files that you have been able to save are legal WAV files.
Is
>> it possible you are reading the "size on disk" value for these files?
>> The "size on disk" value can be la>> Anyway, the symptoms you described during playback of these files all
>> sound like clocking problems. You might want to run some tests to
make
>> sure your clock is accurate and stable.
>>
>> Peter
>>
>>>>> Steven Smolian <[log in to unmask]> 11/17/09 2:06 PM >>>
>> Hi, Peter,
>>
>> The client specified 96/24 WAV. Not much flex here.
>>
>> Steve
>>
>>
>> ----- Original Message -----
>> From: "Peter Alyea" <[log in to unmask]>
>> To: <[log in to unmask]>
>> Sent: Tuesday, November 17, 2009 10:50 AM
>> Subject: Re: [ARSCLIST] Sound Forge issues
>>
>>
>>> Hi Steve,
>>>
>>> Are you saving the files in WAV format? I don't think Sound Forge
will
>>> allow you to save a file beyond the legal limit for the file type.
>> Also,
>>> what makes you state that the files are saving reluctantly? Is there
a
>>> warning dialog box that pops up?
>>>
>>> Peter
>>>
>>>>>> Steven Smolian <[log in to unmask]> 11/16/09 5:41 PM >>>
>>> Hello, Peter et al, (Al, are you out there?)
>>>
>>> I'm formatted in NTFS. It seems to be saving files, albeit
>> reluctantly,
>>>
>>> above 2G but not by much- the longest is 2123xxxkb, It played back
ok-
>>> this
>>> times.
>>>
>>> To be on the safe side, I think I'll divvy them up into .1 and .2
>>> halves. -
>>> unless you think I can safely avoid the nuisanace. Thoughts?
>>>
>>> Steve
>>>
>>> ----- Original Message -----
>>> From: "Peter Alyea" <[log in to unmask]>
>>> To: <[log in to unmask]>
>>> Sent: Monday, November 16, 2009 10:40 AM
>>> Subject: Re: [ARSCLIST] Sound Forge issues
>>>
>>>
>>>> If you are having problems, you might want to check that your hard
>>> drive
>>>> is formatted as NTFS and not FAT32. Also, more recent versions of
>>> Sound
>>>> Forge will record to a buffer beyond the 2GB limit, but will not
>> allow
>>>> you to save the data out to a 2GB limited file format. WAV64 and
RAW
>>> do
>>>> not have the file size limit. RF64 would work as well, but I don't
>>> know
>>>> if it is implemented yet.
>>>>
>>>> Best
>>>>
>>>> *******************************
>>>> Peter Alyea
>>>> Digital Conversion Specialist, Preservation Reformatting Division
>>>> Library of Congress
>>>> (202) 707-5343
>>>> [log in to unmask]
>>>>>>> Raphaël Parejo-Coudert
>>>> <[log in to unmask]> 11/16/09 9:58 AM >>>
>>>> Hello!
>>>>
>>>> Many sound editors limit the files to two hours in length. I'm
using
>>>> Peak pro 6.1.1 on Mac OS X, I get the same results!
>>>>
>>>> Best regards.
>>>>
>>>> --
>>>> R. PAREJO-COUDERT
>>>>
>>>> Ethnomusicologue / Ethnomusicologist / Etnomusicólogo
>>>>
>>>> Anthropologie visuelle et sonore
>>>> Visual and Sound Anthropology
>>>> Antropología visual y sonora
>>>>
>>>> Archives sonores - Archivos sonoros - Sound Archives
>>>>
>>>> °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le (El) Mon, 16 Nov 2009 16:38:21 +0200, Shai Drori, wrote me / m'a
>>>> écrit / me escribió:
>>>>
>>>>
>>>>
>>>>>It has to do with an old windows file limit of 2Gb. New systems can
>>>>>record longer files but it's a try and see what happens deal. You
>>>>>shouldn't have a problem with 1 hor tapes.
>>>>>Shai
>>>>>
>>>>>Steven Smolian wrote:
>>>>>> I recall seeing on line the comment that Sound Forge files are
>>>> limited
>>>>>to two hours in length. I can't find anything about this is the SF
8
>>>>>book, but I seldom think of the same words for a problem as does
the
>>>>>index maker. I'm using SF 10.
>>>>>>
>>>>>> I am working with a group of tapes of about one hour in length
>> being
>>>>>saved as 96/24 files, c. 2.5 times the size of 44.1/16 files.
>>>>>> Am I correct in assuming the 2 hour limit relates to files at the
>>>>>44.1/16 type and those requiring greater real estate have to fit
this
>>>> limit?
>>>>>> I've noticed that one I saved played back first at regular speed
>> but
>>>>>in all subsequent playbacks at half speed. The one I recorded next
>>>> quit
>>>>>recording about half-way through and, though peaking at -4,
crackled
>>> in
>>>>>playback as if levels were past zero.
>>>>>>
>>>>>> The storage medium showed two-thirds of the disc remained unused.
>>>>>>
>>>>>> Should I divide these 1 hour, 96/24 files to accommodate the
>> nominal
>>>>>limit of Sound Forge?
>>>>>>
>>>>>> Steve Smolian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>