Thanks for your attention on this, Charles. I'm moving this thread away from the original AIFF thread.
There are two major and separate issues.
Thanks. Were you also able to find the link to your original post that we missed?
CRASH on INITIAL RECORD
1. Charles' reply to PaulBoston:
This is our visual representation of the individual audio samples. Sometimes in a new recording in the public beta build, the zoom level of the Editor panel is at its maximum zoom level. If you zoom out during the recording, does the behavior change at all?
Your response implies that you know of this issue and have fixed it because you refer to the public beta build.
It would be helpful to us if you would acknowledge some of the fixes you've made to obvious bugs like this one. Better yet, suggest temporary workarounds so we can use the beta more effectively.
The problem here is that Audition frequently crashes when this happens so zooming is impossible. Maybe crash is too strong because sometimes, if you have the patience to wait out the beachball for a very long time, AA4 recovers and zooms itself out. If it doesn't recover itself, and you force quit/Resume the aborted session, AA4 sometimes comes back showing that a successful recording actually did start while the beachball was spinning. But there's no way to zoom out while the beachball is spinning. But I guess you know this already.
I'm hesitant to say we've fixed this when the report is still a bit nebulous. I say "public beta build" mostly to cover my rear. Since I badged myself as an employee on this forum, there are some restrictions to what I may and may not say here. At any rate, please try the following (assuming that you're recording an individual file and not recording clips in the multitrack):
- If you are recording a _new_ file by simply pressing the [ Record ] button, please try creating the file first (e.g. File > New > Audio File…)
- Can you try your recording without the "Include markers and metadata in recordings and multitrack mixdowns" checked? This option is in Preferences > Markers & Metadata. Does this make a difference?
The reasoning behind #1 is to see if you can get around the zoom issue if that is causing your instabilities.
The reasoning behind #2 is that we typically try to write metadata to the file after its recorded.
Regarding the zooming, what method(s) of zooming are you using (e.g. mousewheel, navigator bar, +/- keys, zoom buttons in UI)?
UNRELIABLE RECORDING OF LONG SESSIONS
This problem might be due to my unusual workflow, but it does expose a recording problem with AA4 that most folks won't encounter.
My workflow is to capture hours-long material, then save selections of the capture to hard drive. After completion, I dismiss the capture without ever saving the capture file.
The problem is this: AA4 will behave erratically after one or two long sessions. It can either spontaneously crash or pause a capture, causing that capture to be unrecoverable. One time after an apparent crash, I let the beachball spin and went to lunch. When I came back, I noticed that the waveform was selected as though capture had stopped. However, AA4 was still unresponsive. It took yet another hour before the waveform could be played.
On the iMac, with its limited resources, I recorded silence for over an hour, dismissed the capture, and started a new recording. A few minutes into the second recording, AA4 reported disk-full cache problems. That gave me a clue that the cache might not have been reset when I dismissed the first capture. So far, I have been able to capture reliably using AA4 if I remember to quit and re-launch AA4 before each recording.
If this problem has also been fixed, a workaround would have saved me numerous hours of failed captures and attempts to understand the problem on my own.
Just to make sure we're using the same nomenclature, when you say "sessions" you're not talking about an actual multitrack session file (e.g. *.sex), but your talking about a period devoted to a particular activity. With Audition, we often use the term session for the former.
I appreciate the effort you've put into trying to figure out the issues you described here. Using beta software can be somewhat frustrating at times, but it definitely benefits the developers (we often find more issues quickly by having a large number of people using that app in different ways) and for the customers (because the product has gone through further testing and refinement based off of the feedback in this beta). I'm not quite sure how to tackle this problem as described, but I'll try to explain our file cache system to see if that helps.
In the Media & Disk Cache preferences, you can choose where Audition's temp file lives. By default, this will be at /Users/<USER_NAME>/Library/Caches/TemporaryItems/Adobe/Audition/4.0/. In there, you'll see one or more files that are labeled "Aduition4Temp" with a GUID afterwards. This is often called our "temp file" or our cache. What goes in this file are things like the following:
1. Recordings in the Waveform Editor (in the Multitrack, we instead record to individual WAV files directly instead of the tempfile).
2. Any processed audio on any of the files you have open. For example, if you change the gain of a region of audio several times, each of those attempts will live there until you close that file. The reason for this is that this allows us to quickly go back and forth between different items in the History Panel.
We always clean up the current tempfile(s) when you quit Audition, but since you've been crashing it may be possible that there are orphaned tempfiles sitting around in that folder. Assuming you don't need to recover any crashed data, it should be safe to just delete that folder when Audition isn't running, and we'll create it on next launch (assuming your preferences still use that as the temp folder location.
Regarding your disk getting full, some of this behavior has been improved since the public beta. We're now better about falling back to the secondary temp folder (if you chose one) when the first gets full and also giving you early warning when you may be low on space.
If you're recording in the Multitrack typically, the entire game is different, so I can explain that further if that's what you're actually doing.
I'm chagrined that I can't find my old post even though I'm sure I reported the crash/zoom problem early on. It must have been a reply to another post. The search feature on the forum page is quite limited and there's a lot of stuff on the forum by now.
Zoom/crash - Thanks for these workaround suggestions. It will take a few days to see if they work because the zoom problem is intermittent. I use the wheel on a Microsoft mouse for zooming. But as I reported, AA4 is frozen and the beachball is spinning, so nothin' works other than force quitting. At all other times, zooming works fine with the wheel. I'll report my results, but if you've already fixed this, we don't need to dwell on it.
Unreliable recording - Quitting AA4 between captures seems to be a successful workaround so far, but further testing is necessary.
My reference to "session" is the time between AA4 launch and quitting the app. I seldom use Multitrack. After capture in Waveform mode, I save selections, apply restoration processes, then dismiss the capture file without saving it.
Thanks for the details on the cache. A disk space warning on the Mac Pro would actually have helped. At least I would have known to attempt a purge of the temp file rather than experiencing ruined captures and crashes. The Mac Pro boot drive has over 1TB of free space and it's a brand new drive with a new install of Snow Leopard, so I'm assuming that hardware and OS contamination are negligible.
In my case, there's no advantage for very large capture and process files to linger after dismissal. I suspect that AA4 might have problems dealing with multiple huge temp files and that eventually brings it to its knees. Is it possible to have a "temp file too big" warning?
I do not record in Multitrack.