Frustrating Bounce to Disk problem

[bpcmxr]

Hi All,

I've been experiencing a maddening problem lately. I'll be bouncing to disk, usually involving some combination of bit depth and/or sample rate conversion. I always convert after the bounce, using the Tweakhead setting. Every once in a while I'll get a track that seems to be bouncing to disk just fine, but at the end of the bounce countdown, where you'd normally then see the conversion progress bar, I get the following message instead:

Could not complete the "Bounce to
Disk..." command because:
Assertion in
"FF_AudioProperty.cpp", line 33.

Right now I'm trying to wrap up an album mastering project. I've got the 12 finished (now 16bit/44.1k) files lined up on a single stereo audio track, sequenced & spaced just right. I'm bouncing each song to disk (converting from dual mono to stereo interleaved) individually and in order for final assembly and PQ subcode editing in JAM 6. Nine of the songs bounce perfectly, but three generate this error message.

Does anyone here recognize this problem? If you do and have any idea how to cure it, I'd be very grateful for your help. I'm slowly going mad here.

Thanks in advance!

[KingFish]

If your session is 30 tracks or less, you can rout all tracks through a stereo bus, open a Stereo Auxillary track, insert your mastering plugins on the aux (this aux is replacing your master track, so delete it) set the output of that Aux to another available stereo bus.

Open a new stereo audio track... set it's input, to the bus that you've assigned your Aux, stated above, rec enable the track, highlight the exact start time, to the exact end time (the same way you would in a bounce) and pop it into record.

When you are finished, from the audio tab, above the regions list, select "Export Selected Audio As" pick 44,100 16 bit stereo interleaved, and put it, where you were going to be putting your bounced files.

if you're maxed out on your track count, you may want to bus some tracks in your session, to a new audio track, record your sub mix, then disable the vioce on those original tracks.

Good Luck !

[Infa]

bpcmxr, as KingFish gave you a good WORK AROUND, you should still fix this problem you are having, because rightfully you should be able to do what you are trying to do..

So, here is your problem, and the reason it is happening, and the SOLUTION ---

The problem you are having is caused by corrupted FADE files in the particular session. Trashing the "Fade Files folder" in the session you are having problems in and letting Pro Tools rebuild them automatically (you know how it does that when you are missing fade files) will solve the problem. Then you will be able to "Bounce to disk" just fine !!

Then just do that to every song you are having these problems on... Tell me if it works !!


Hope This Helped--

[bpcmxr]

Thanks a lot, guys, for putting the time into these replies - I do appreciate it. Infa is right - you offer a good workaround, KingFish, but it still leaves me with the original problem which, I'm sorry to report, is also not cured by trashing the session's Fade Files folder.

I've since received a private email from another DUC lurker who has, in addition to trashing his Fade Files folder, has trashed his PT Preferences and even gone so far as completely re-installing PT in an attempt to solve this problem, with no luck.

This is a real stumper for me so far. Does anyone here even know what the hell an 'Assertion in "FF_AudioProperty.cpp", line 33' error message even means? Digi??

The ONLY time I've ever been able to successfully bounce a file after this problem had already raised its ugly head was by adjusting the bounce boundaries on a multichannel mix. I very slightly adjusted the position of the breakpoints (in time) of the bottom (-Inf) of the fade-in and fade-out automation on my master fader, reselected the modified distance between and presto - the bounce and conversion went down just fine. That single fix now seems a fluke, though, since it has never worked for me since.

The session which prompted my original post above wasn't a mix, and didn't feature any automation. I'd already done my EQ & compression on the original 24bit/48k mixes in a separate session and had successfully bounced and converted them all to 16bit/44.1k files. I then created a new session where I lined up these new bounces in their proper order on a single stereo audio track. By trimming the fronts & backs of each song's region I was able to precisely satisfy my client's requests for the timing between tracks. The idea was to then bounce & convert (from multiple mono back to stereo interleaved) each trimmed region (song) individually, so that when I reassembled the running order in JAM6, creating zero pauses between tracks would maintain the spacing I'd created in PT. All of this worked out perfectly, except that of the twelve songs (regions), three of them would not convert after bouncing, and treated me to the above error message every time.

Anyhow, the way I finally got around this was to just take the original 16bit/44.1k bounces of these three songs (generated from the earlier 24bit/48k mastering session), import them into JAM and into their respective places in the sequence, and then use JAM's Track Trim function to arrive at the desired timing between these tracks and their neighbors. More cumbersome and time-consuming than doing it in PT, but in the end it got the job done.

Sorry for the length of this post, but I want to set the scene with as much context and detail as possible just in case someone from Digi drops in, reads this, and has some idea about what could be causing this problem.

[Infa]

Does anyone here even know what the hell an 'Assertion in "FF_AudioProperty.cpp", line 33' error message even means? Digi??

Yes ,, trust me -- "FF" stands for Fade File - the rest is self explanitory. One of your "Audio Properties" in your Fade Files has been corrupted,, that is THE ONLY thing it can be, and that is WHAT that message means... BUT HERE is why you may be experiencing the issue still even after trashing your Fade File Folder.... Answer me this , Did you at all ever "Consolidate" a region in this session ??? If you did,, well that is where your problem lies... You must have had a corrupted fade file back before you consolidated the region/track, and when you "consolidated" a track/region you accidently with out knowing consolidated the corruption from a fade file on that tracks region you were consolidating INTO the new consolidated part,,, and therefore it will never go away...

So even though you throw away your corupted fade file in your fade files folder, that will not help because there is ALSO a copy of that corrupted fade file now INSIDE of that new consolidated region...

So now you have to get BACK to before you consolidated the regions somehow, so there is NO consolidated regions in your whole session, save the session, THEN quit Pro Tools, then go and throw away your Fade Files Folder, then go and launch your session, Pro Tools will then say it cant find some missing fade files, let it re-create them all, THEN double check to see if it bounces to disk correctly , IT SHOULD NOW, THEN you can go and consolidate all the regions/tracks you want, because then new, good, perfect, UN-CORRUPTED fade files will be incorporated into the consolidations....

Use that method also all the time to, even with new sessions. BEFORE you consolidate regions/tracks MAKE sure your session bounces to disk properly....

Or , for this session, just do what King Fish said for now,, and just be more careful in the future before you consolidate a region/track.

--Get it-- ??

Hope This Helps --

[SimpleNatureSpirit]

Is this a joke or what!
Audio corruption is one of Digi's most formitable foes but when you mention it to them, they turn their heads.
I have noticed since V6 came out that fade files have a quirk to them. It has something to do with being 'intelligent'. When I adjust the fade-in profile, PTLE adjusts the fade-out profile although I did not want this. I was working in a session last night in v6.4cs6 that did exacly this and messed up some critical cross fades.
I think all this is somewhere in the new caching algorythms and files that just make all version 6 PTLE sessions 'unstable and quirky'. One thing I know, the quieter Digi is on a problem the harder they are working on solving it.
I am planning to bounce my files the old fashion way, to a Masterlink. That way I can hear what I get, what I get I can preview, what I preview will be written to the CD. I can send 24/96 analog to the Masterlink and have it record at 16/44.1. If I don't like it, I adjust with my mastering tools till it's right

[bpcmxr]

FIXED!

I really do appreciate the time and effort you and KingFish have put into trying to help me solve this problem, Infa, but the problem has turned out to be my DAE Buffer setting. There were no Fade Files associated with the three tracks that were giving me problems, and if there were consolidated regions in any of the songs, they were consolidated before the project reached me - I was dealing only with the finished stereo mixes.

Anyhow, today I received another email from that same user I mentioned earlier who was experiencing the same problem. He forwarded Digi Tech Support's advice:

"Hi,

What do you have your DAE playback buffer set to. It should be left at the default of 2. If you have it set to higher values it can cause Pro Tools to throw this error when bouncing to disk. Please let me know if this does not resolve your issue.

Best regards,
Digidesign Technical Support"

I checked, and sure enough I found I had long ago set mine to 8, probably thinking - fast Mac, lots of RAM, set it to the max, etc. I set it back to 2, and whaddya know? The three files that I previously couldn't successfully bounce out of my 16bit session to save my life, bounced & converted perfectly, the first time each time.

I still don't understand WHY this should have been a problem, and only on these seemingly random files, but I'm very happy for the fix!

[Infa]

I am happy too for you. I also got the email from the same guy, because I was trying to see him through this too. I am glad the both of you got this ironed out. that is the important thing.

I am just sorry I couldn't give you that info, and I hope I caused no confusion. That error message means what I said, and usually only has that fix for it, BUT I guess if you have a buffer setting set to high, what happens is it flashes that particular message for some reason, and average problem solving can not come into play.... Plus I just figured you were rockin' the default buffer setting for mixes. It is a good idea to ALWAYS do that... Sorry I didn't ask you that from the beginning...

But that is the beauty of Digi tech, they truly know it all .... And now we at least know that there are TWO possible solutions for that error message....

But the most important thing is you two are up and running fine now -- Happy Mixing !!!

[special_K]

So even though you throw away your corupted fade file in your fade files folder, that will not help because there is ALSO a copy of that corrupted fade file now INSIDE of that new consolidated region...

hi Infa,

i think that's not right because when you consolidate a region with fade files, the fades will be rendered to the audio file and, from that moment, aren't fade files anymore. correct me if i'm wrong.

peace, K

[Infa]

Yeah,, I was thinking that too, and I can NOT correct you if your wrong because I don't know for SURE. (LOL)
But I was thinking of ALL possibilities. And as I could have been wrong, (and in this instance I was, because it was NOT the issue), the question remains NOW as you bring it up, is, is that even possible ??

So the reasons for my figurings are , as you ARE right the fades get rendered INTO the consolidation and are not fade files anymore, I am THINKING it is possible for the corruption of the original file itself to be rendered INTO the consolidation. So it is NOT a fade file any longer, sure,,, but that does NOT mean it didn't render the corruption INTO the new consolidated region...I mean think about it, if the 0's and 1's are off and corrupted, that is what it is going to read, and therefore render INTO the consolidated piece. I mean it does not have a brain ya know,, so it doesn't know to NOT transport a bad part... (of coarse this is all ONLY applicable IF you have a corrupted fade file or audio piece to begin with that you accidently consolidate into a new region)..

Now as I definetely could be wrong,,,, this is a thing to think about. And truly will never know the answer unless Digi rings in to tell us... And actually it IS possible they don't even know for sure... But no mortal on this forum can tell me that they are 100% sure this is NOT possible. Sure they will try,, and as they are sure with in themselves, I am not sure with them....

I will take Digi's word on it though... IF and only IF they have tried this, and know for sure. NOT if they are just going by some white paper "should be's, and should be not's" .......

This IS a great question though, and I would be thrilled to hear what others thought of this --

So if you popped in late the shortened version of the question IS :

Is it possible if you have a corrupted Fade File OR audio piece in a section on a track you are about to consolidate, and you then consolidate it all with out fixing the corruption in the fade file OR audio piece, is it possible to render ANY of them corruptions INTO the consolidated new region ?????

Let the games begin --