*ANYONE* know how to tell Cool Edit Pro 2 to stop leaving .pk files
everywhere it goes? My HD is full of them and they're a major pain in the
ass to remove individually.

I can't find the blasted option anywhere that will make the program either
not use .pk files, or at the very least, wipe them out when the program is
shut down.

"Chief Wiggum" wrote in message

*ANYONE* know how to tell Cool Edit Pro 2 to stop leaving .pk files
everywhere it goes? My HD is full of them and they're a major pain in
the ass to remove individually.

I can't find the blasted option anywhere that will make the program
either not use .pk files, or at the very least, wipe them out when
the program is shut down.

There's an option that controls whether they are saved.

Options, Settings, View, Save Peak Cache Files.

Turning this feature off can substantially increase the time it takes to
load files you've worked on before or recorded in CEP.

"Chief Wiggum" wrote:

*ANYONE* know how to tell Cool Edit Pro 2 to stop leaving .pk files
everywhere it goes? My HD is full of them and they're a major pain in the
ass to remove individually.

I can't find the blasted option anywhere that will make the program either
not use .pk files, or at the very least, wipe them out when the program is
shut down.

The .pk file lets you load a previously loaded wav file instantly. If you read
the FAQ that is part of the Help files, this is the first thing you see:

Q: Why does Cool Edit 2000 create files with the extension ".pk" alongside my
audio files?

A: These are Peak Files. They enable Cool Edit 2000 to load, save, and redraw
audio files more quickly than it could do without them. You can safely delete
these Peak Files, or turn their creation off altogether in
Options/Settings/System. Without them, larger audio files will take longer to
load.

Harvey Gerst
Indian Trail Recording Studio
http://www.ITRstudio.com/

You can have windoze search all drives for *.pk, then you can delete them all.
Or from the command line in the root directory of each drive: del /q /s *.pk


Chief Wiggum wrote:

*ANYONE* know how to tell Cool Edit Pro 2 to stop leaving .pk files
everywhere it goes? My HD is full of them and they're a major pain in the
ass to remove individually.

I can't find the blasted option anywhere that will make the program either
not use .pk files, or at the very least, wipe them out when the program is
shut down.

thanks !!!!!


"S O'Neill" wrote in message
...

You can have windoze search all drives for *.pk, then you can delete
them all.
Or from the command line in the root directory of each drive: del /q
/s *.pk

S O'Neill wrote:


You can have windoze search all drives for *.pk, then you can delete them all.
Or from the command line in the root directory of each drive: del /q /s *.pk

Use the latter at your own risk!

Arny wrote:

There's an option that controls whether they are saved.

Options, Settings, View, Save Peak Cache Files.


It would be nice if they'd let you control *where* they are saved, like
you usually can with cached files, so you get one folder with all of
them, to be cleaned out at will.


Chris


______________________________________
Please remove the r from my address to reply by email

"Chris Smalt" wrote in message
...


Arny wrote:

There's an option that controls whether they are saved.

Options, Settings, View, Save Peak Cache Files.


It would be nice if they'd let you control *where* they are saved, like
you usually can with cached files, so you get one folder with all of
them, to be cleaned out at will.


So, what's the big deal? *.pk files are all saved (on my computer) in the
same folder as its associated wave/aif file, not "all over the computer".
For an almost 4 Mb file the associated .pk file was only 63 kb. Hardly
worth worth thinking about with today's hard drive sizes. I rather like the
almost instant loading feature, made possible by the peak files. The lack
of this feature was what turned me away from Sound Forge a number of years
ago. It was an okay 2-track editor, but the interminedble wait for files to
load and to re-write after changes put me off. I'm a big fan of those .pk
files, as you can tell.

Steve King

"Chris Smalt" wrote in message

Arny wrote:

There's an option that controls whether they are saved.

Options, Settings, View, Save Peak Cache Files.


It would be nice if they'd let you control *where* they are saved,
like you usually can with cached files, so you get one folder with
all of them, to be cleaned out at will.

This could get messy if you have several .wav files with the same name, but
in different folders. By putting the .pk file in the same folder as the .wav
file, they keep things simple for them and us.

Arny Krueger wrote:

Turning this feature off can substantially increase the time it takes to
load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.


Kind regards

Peter Larsen

--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

"Peter Larsen" wrote in message
...
Arny Krueger wrote:

Turning this feature off can substantially increase the time it takes to
load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.

Tell us more about this. I've been a daily user of CEP for years, since it
first became available. I've never had a corrupted file. If a file is
corrupted, does the peak file still load? I can see how that might be bad
if one were in a live situation such as sound cues in theater. Tell us
more.

Steve

Steve King wrote:

Turning this feature off can substantially increase the time it takes to
load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.

Tell us more about this. I've been a daily user of CEP for years, since it
first became available. I've never had a corrupted file. If a file is
corrupted, does the peak file still load? I can see how that might be bad
if one were in a live situation such as sound cues in theater. Tell us
more.

It is kinda a prehistoric event, it was with CE96 on my P133 and with a
Soundblaster AWE32 sound card. The cause of file corruption was
determined by Syntrillium Support to be an outdated driver, upgrading
the driver prevented that type of file corruption from happening again.
What was unpleasant about it was that the file loaded and displayed as
"perfect". It was only modding, playing, whatever - sheesh, can't
rememember this - that revealed that it was garbled, apparentlly with a
"modulo function", i. e. contained the same short segment repeated again
and again.

Steve


Kind regards

Peter Larsen

PS!:

Original topposted email reply from syntrillium support:

Hello-

This is an issue with your sound card drivers. Download the latest
drivers
available for your sound card. If you have the latest drivers,
reinstall
them. This type of corruption usually occurs when the drivers go bad.

Best Regards,

Steve Schaefer
Technical Support
Syntrillium Software

Note: Please quote this entire email in any response. Thanks!
On-line support is available at http://support.syntrillium.com/

At 11:36 PM 10/6/99 +0200, you wrote:

Hi,

subject header says it, pray forgive me for attaching a screen snapshot,
but I think it is easier to see on the picture what happens when I try
to convert that file to mono than explain it, playing with the cache
size and type (system/Cool Edit) only changes how it goes wrong - the
last part of the file gets inserted multiple times at the start .....

????????

Kind regards

Peter Larsen




--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

"Peter Larsen" wrote in message
...
It is kinda a prehistoric event, it was with CE96 on my P133 and with a
Soundblaster AWE32 sound card. The cause of file corruption was
determined by Syntrillium Support to be an outdated driver, upgrading
the driver prevented that type of file corruption from happening again.
What was unpleasant about it was that the file loaded and displayed as
"perfect". It was only modding, playing, whatever - sheesh, can't
rememember this - that revealed that it was garbled, apparentlly with a
"modulo function", i. e. contained the same short segment repeated again
and again.


Glad to have the details. I think that I'll keep on keeping on with the .pk
files. I'm not a patient guy. The projects I do often contain dozens of
files. If I had to wait for peak file rebuilds for each, I'd go bonkers.
Thanks for the clarification.

Steve King

"Steve King" wrote in message
Glad to have the details. I think that I'll keep on keeping on with the
..pk
files. I'm not a patient guy. The projects I do often contain dozens of
files. If I had to wait for peak file rebuilds for each, I'd go bonkers.

Me too. I often record and edit 2-3 hour waveforms at a time. It takes
about 10-15 minutes to load some of them. I'd hate to have to wait every
time I opened the file, so I like the .pk files.

How do other programs handle loading of .wav files? Does it take long?

Thomas Bishop wrote:

How do other programs handle loading of .wav files? Does it take long?


BIAS Peak is pretty quick, on my G4/933/OSX. It doesn't use such a mechanism;
it rebuilds the view every time.

Thomas Bishop wrote:

Me too. I often record and edit 2-3 hour waveforms at a time. It takes
about 10-15 minutes to load some of them. I'd hate to have to wait every
time I opened the file, so I like the .pk files.

Is your disk setup wise?


Kind regards

Peter Larsen


--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

"Peter Larsen" wrote in message

Steve King wrote:

Turning this feature off can substantially increase the time it
takes to load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.

As you subsequently clarified this happened long ago under circumstances
that are IME exceedingly rare - I've never seen anything untoward happen.

I frequently edit half-hour or longer sessions composed of 12 each 32 bit,
44 KHz files. They are 250-300 megabytes each. Needless to say, the .pk
files are lifesavers.

Arny wrote:

This could get messy if you have several .wav files with the same name, but
in different folders.


Programs that put their waveform cache files in a single folder give
them custom names, for instance using a numbering scheme, so duplicate
file names aren't an issue.


Chris


______________________________________
Please remove the r from my address to reply by email

"Peter Larsen" wrote in message
It is kinda a prehistoric event, it was with CE96 on my P133 and with a
Soundblaster AWE32 sound card. The cause of file corruption was
determined by Syntrillium Support to be an outdated driver, upgrading
the driver prevented that type of file corruption from happening again.
What was unpleasant about it was that the file loaded and displayed as
"perfect". It was only modding, playing, whatever - sheesh, can't
rememember this - that revealed that it was garbled, apparentlly with a
"modulo function", i. e. contained the same short segment repeated again
and again.

Not clear how turning pk on or off would have made any difference.
Surely doesn't outweigh the advantages of keeping the pk files.

In article writes:

"Peter Larsen" wrote in message
What was unpleasant about it was that the file loaded and displayed as
"perfect". It was only modding, playing, whatever - sheesh, can't
rememember this - that revealed that it was garbled, apparentlly with a
"modulo function", i. e. contained the same short segment repeated again
and again.

Not clear how turning pk on or off would have made any difference.
Surely doesn't outweigh the advantages of keeping the pk files.

The audio is still corrupt. I think that what Peter suggests is that
with the .pk file present, it looks on screen like everything's OK
until you actually start working with the audio content. With the
screen display drawn from a different file than the one containing the
audio, an error is temporarily concealed that would be perfectly
obvious once you tried to play or edit the track.

About the only way I can see this would help is if you discover that a
track which you can replace (because the talent is still around) has
gone to the great bit bucket in the sky. If you have the .pk file (but
not the audio), this will assure that the singer will be on tour for
three years when you start auto-tuning his track and discover that
it's been corrupted.


--
I'm really Mike Rivers - )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Mike Rivers wrote:

The audio is still corrupt. I think that what Peter suggests ...

You got my concerns right.

I'm really Mike Rivers - )


Kind regards

Peter Larsen

--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

Richard Crowley wrote...
Not clear how turning pk on or off would have
made any difference. Surely doesn't outweigh
the advantages of keeping the pk files.

"Mike Rivers" wrote ...
The audio is still corrupt. I think that what Peter
suggests is that with the .pk file present, it looks
on screen like everything's OK until you actually
start working with the audio content. With the
screen display drawn from a different file than the
one containing the audio, an error is temporarily
concealed that would be perfectly obvious once
you tried to play or edit the track.

Yes, of course the audio is still corrupt. So in the event
(extraordinarily rare to nonexistent by ALL accounts)
where the main file is corrupt but pk file OK, you are
given a false sense of security *for a few seconds*
(until you actually play the file).

And avoiding that few seconds is supposed to be worth
spending hours (over the course of years of good files)
waiting for files to be scanned every time you open them?
I surely don't think so. Apparently I have a very different
sense of time and aggravation.

And, of course, Adobe Auditon continues the pk tradition
of Syntrillium, so this isn't a discussion limited to CEP or
CE2K, etc.

Richard Crowley wrote:

Yes, of course the audio is still corrupt. So in the event
(extraordinarily rare to nonexistent by ALL accounts)
where the main file is corrupt but pk file OK, you are
given a false sense of security *for a few seconds*
(until you actually play the file).

As you will see if you go back and read the appended email-exchange with
Syntrillium support I didn't play the file, I converted it without ever
detecting that it was garbled. I don't know how you do things, but there
are plenty audio chores to do that do not require listening ....

And, of course, Adobe Auditon continues the pk tradition
of Syntrillium, so this isn't a discussion limited to CEP or
CE2K, etc.

The excellent point has been made that it is a paolithic event involving
a paolithic sound cards drivers.


Kind regards

Peter Larsen

--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

In article writes:

As you will see if you go back and read the appended email-exchange with
Syntrillium support I didn't play the file, I converted it without ever
detecting that it was garbled. I don't know how you do things, but there
are plenty audio chores to do that do not require listening ....

Oh, I can't resist the urge to give a listen anyway. Sorry, I no
longer have the rest of the thread in front of me. What chores do you
perform on an audio file that don't require listening? Things like
sample rate conversion, maybe? Or batch conversion from WAV to MP3? I
had to work hard to think of those, so I guess _I_ don't do that sort
of chore enough to worry about.

--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Recently, Mike Rivers posted:

In article
writes:

As you will see if you go back and read the appended email-exchange
with Syntrillium support I didn't play the file, I converted it
without ever detecting that it was garbled. I don't know how you do
things, but there are plenty audio chores to do that do not require
listening ....

Oh, I can't resist the urge to give a listen anyway. Sorry, I no
longer have the rest of the thread in front of me. What chores do you
perform on an audio file that don't require listening? Things like
sample rate conversion, maybe? Or batch conversion from WAV to MP3? I
had to work hard to think of those, so I guess _I_ don't do that sort
of chore enough to worry about.

Even those chores require listening, unless you really don't care whether
the results sound good. I'm also curious about this claim, as I can't
think of any operation that I'd do on an audio file that wouldn't benefit
from listening to the results.

Neil

"Neil Gould" wrote in message
ink.net
Recently, Mike Rivers posted:

In article
writes:

As you will see if you go back and read the appended email-exchange
with Syntrillium support I didn't play the file, I converted it
without ever detecting that it was garbled. I don't know how you do
things, but there are plenty audio chores to do that do not require
listening ....

Oh, I can't resist the urge to give a listen anyway. Sorry, I no
longer have the rest of the thread in front of me. What chores do you
perform on an audio file that don't require listening? Things like
sample rate conversion, maybe? Or batch conversion from WAV to MP3? I
had to work hard to think of those, so I guess _I_ don't do that sort
of chore enough to worry about.

Even those chores require listening, unless you really don't care
whether the results sound good. I'm also curious about this claim, as
I can't think of any operation that I'd do on an audio file that
wouldn't benefit from listening to the results.

When I transcribe analog to digital, I generally edit the song boundaries
completely visually. But I confess that I listen to every CD I burn before I
send it out.

"Arny Krueger" wrote ...-
When I transcribe analog to digital, I generally edit the song boundaries
completely visually. But I confess that I listen to every CD I burn before
I
send it out.

Every TITLE, or every COPY? There's not enough days
in the week to listen to every COPY! Especially at 48x!

"Neil Gould" wrote in message
ink.net...
Recently, Mike Rivers posted:

In article
writes:

As you will see if you go back and read the appended email-exchange
with Syntrillium support I didn't play the file, I converted it
without ever detecting that it was garbled. I don't know how you do
things, but there are plenty audio chores to do that do not require
listening ....

Oh, I can't resist the urge to give a listen anyway. Sorry, I no
longer have the rest of the thread in front of me. What chores do you
perform on an audio file that don't require listening? Things like
sample rate conversion, maybe? Or batch conversion from WAV to MP3? I
had to work hard to think of those, so I guess _I_ don't do that sort
of chore enough to worry about.

Even those chores require listening, unless you really don't care whether
the results sound good. I'm also curious about this claim, as I can't
think of any operation that I'd do on an audio file that wouldn't benefit
from listening to the results.

Neil

The announcer tracks I do often result in many smaller wave files. I edit
and check those. Then, I often do a batch conversion to MP3 for internet
delivery to the client. I do not check each MP3. I've had only one client
have a problem with a file. Turned out to be his hardware. Of course, I
know that I can recreate these files, recompress to MP3 and resend on very
short notice, when necessary, and that eliminates the stress I might feel if
I were dealing with a music track after the musicians go on tour to Japan,
and I were leaving instantly for a vacation in Tahiti.

I do listen to each CDR that I am sending out for duplication but not to
each CDR that I may be providing in small numbers as client take-aways. I
do spot check, though.

Steve King

In article . net writes:

sample rate conversion, maybe? Or batch conversion from WAV to MP3?

Even those chores require listening, unless you really don't care whether
the results sound good.

Certainly you'd want to listen afterward (unles as you say you don't
care about the results) but if you know for sure what file you want to
convert, you may not need to listen to it first to check. I guess the
point is that you feed a file name to a process outside of Cool Edit,
and that process (rather than Cool Edit or your ears) informs you that
the file is hosed.

I suspect that the surprise is the most annoying part, since you can't
do anything about the damage.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Recently, Mike Rivers posted:

writes:

sample rate conversion, maybe? Or batch conversion from WAV to MP3?

Even those chores require listening, unless you really don't care
whether the results sound good.

Certainly you'd want to listen afterward (unles as you say you don't
care about the results) but if you know for sure what file you want to
convert, you may not need to listen to it first to check. I guess the
point is that you feed a file name to a process outside of Cool Edit,
and that process (rather than Cool Edit or your ears) informs you that
the file is hosed.

I suspect that the surprise is the most annoying part, since you can't
do anything about the damage.

Can you say "back up"? I knew you could! ;-)

IMO, that is the bottom line of this discussion. CoolEdit's pk files save
a *ton* of time... and backup files remove the likelihood of a hosed file
creating havoc in your day. And, you don't have to back up the pk files.
So, good disc management and back up practices provide a far more
practical work environment than simply working without pk files.

Neil

"Richard Crowley" wrote in message

"Arny Krueger" wrote ...-
When I transcribe analog to digital, I generally edit the song
boundaries completely visually. But I confess that I listen to every
CD I burn before I send it out.

Every TITLE, or every COPY? There's not enough days
in the week to listen to every COPY! Especially at 48x!

Every title or master copy, of course. I do proof the copying procedure to
make sure is it bit perfect, but not every copy.

Mike Rivers wrote:

I suspect that the surprise is the most annoying part, since you can't
do anything about the damage.

The surprise was the unpleasant part, nothing irreversible happened, it
was way back when I analyzed lotsa lotsa audio files. The realisation of
the potential for diastrous save-back remains. Such a realisation is
"good for ya", one learns to aim for having diskspace enough to keep
every step of a project until done. Not all aims are achieveable.

I'm really Mike Rivers )


Kind regards

Peter Larsen

--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

Neil Gould wrote:

IMO, that is the bottom line of this discussion. CoolEdit's pk files save
a *ton* of time... and backup files remove the likelihood of a hosed file
creating havoc in your day.

Yes. It is of course a weighing of how many iterations of a project you
want to store.

So, good disc management and back up practices provide a far more
practical work environment than simply working without pk files.

I will probably rethink my strategy in case of multitrack projects.

Neil


Kind regards

Peter Larsen

--
************************************************** ***********
* My site is at: http://www.muyiovatki.dk *
************************************************** ***********

Recently, Peter Larsen posted:

Neil Gould wrote:

IMO, that is the bottom line of this discussion. CoolEdit's pk files
save a *ton* of time... and backup files remove the likelihood of a
hosed file creating havoc in your day.

Yes. It is of course a weighing of how many iterations of a project
you want to store.

Understood! My workflow includes copying an entire project to a "safe"
disc, then burning a DVD backup of a project before making any risky
changes (including deleting "unwanted" edits which may be "wanted" later
on). Even though this takes time to execute, there is little risk of
painting myself into a corner.

Best regards,

Neil

Thomas Bishop wrote:


How do other programs handle loading of .wav files? Does it take long?

Nearly all serious programs use overview files - even Sound Forge has
recently gone that way.

Cheers.

James.

On or about Fri, 05 Dec 2003 20:45:28 +0100, Peter Larsen allegedly wrote:

Arny Krueger wrote:

Turning this feature off can substantially increase the time it takes to
load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.


You also need to be careful if you modify or replace a file with another
audio program (as they all seem to use different formats, or at least
extensions).

If you delete any associated peak/profile/overview files, a new one will
be generated when you open the file, and it will then display correctly.
Otherwise what you see on the screen may not be what the sound really is!


Noel Bachelor noelbachelorAT(From:_domain)
Language Recordings Inc (Darwin Australia)

(Noel Bachelor) wrote in
:

On or about Fri, 05 Dec 2003 20:45:28 +0100, Peter Larsen allegedly
wrote:

Arny Krueger wrote:

Turning this feature off can substantially increase the time it
takes to load files you've worked on before or recorded in CEP.

True, but having it on can have you not detect a corrupted file. One
experience was enough. It is off and stays off.


You also need to be careful if you modify or replace a file with
another audio program (as they all seem to use different formats, or
at least extensions).

If you delete any associated peak/profile/overview files, a new one
will be generated when you open the file, and it will then display
correctly. Otherwise what you see on the screen may not be what the
sound really is!


Noel Bachelor noelbachelorAT(From:_domain)
Language Recordings Inc (Darwin Australia)


Cooledit checks the file (presumably using date modified) and rebuilds
anyway.