48 kHz 16 bit, music created in Audition 3. Level burps up again after the final fade. Deleting the .sfk file alters it, sometimes the vox, sometimes the music underlay. A probable workaround is perhaps to make an intermediate render and then fade the audio on that. This is not the first time, I have encountered audio re-burb after fade envelope, but it is more of a nuisance on a 62 seconds file than on a longer file. And sometimes it is audio from the middle of the file and not just the end coming up.

Here is an example, the file in Vegas burped the music track, but the render burps the audio and inserts half a word from earlier in the narration ...

So I open the audio files in my audio editor and add the fades there, yes, less flexible, but initial and final fades on two files, so what. Then I remove the fade of the music track, delete .sfk files, restart vegas and get this, that looks like a snippet from the music track, but just plays white noise ....

Are you able to share the file? (on a cloud service such as Dropbox, Google Drive, OneDrive, mega.nz, wetransfer.com or mediafire.com. Not uploaded to the forum, which would recompress it).

Silly questions, but important ones: Have you checked to see if your hard drive(s) are fragmented? Try defragging. Also, is your media (audio and video) on a drive OTHER than the main OS drive on your computer?

I agree, the question is not well thougth through. This is a 61 second project with some still images, a music bed and a voiceover. The problem seems to to be a variation of the audio file pointer corruption that occasionally caused gross dislocation in time of audio files in V14. I thought briefly that it was because of the three effects that are put on the audio track by default, but remembering to remove them made no difference.

Are you able to share the file? (on a cloud service such as Dropbox, Google Drive, OneDrive, mega.nz, wetransfer.com or mediafire.com. Not uploaded to the forum, which would recompress it).

Nick, isn't the example audio file I uploaded here enough? - a drastic level change where the fade out should go to nil is quite obvious, also I don't think that a mp3 audio file is recompressed. The competion conditions prohibit publicdisclosure of the file currently, but not that I try to recreate the issue in a test project, I'll see if I can do that, I do have a dropbox, so sharing the entire project would be possible - that would be what makes sense, right?

Are you able to share the file? (on a cloud service such as Dropbox, Google Drive, OneDrive, mega.nz, wetransfer.com or mediafire.com. Not uploaded to the forum, which would recompress it).

Nick, isn't the example audio file I uploaded here enough? - a drastic level change where the fade out should go to nil is quite obvious, also I don't think that a mp3 audio file is recompressed...

I didn't realise that I could save the mp3 file with a right-click from the player on the forum.

It plays with that problem in all my players.

To troubleshoot it on other users' PCs, we need to get hold of the source audio file, not a rendered file.

...The competion conditions prohibit publicdisclosure of the file currently, but not that I try to recreate the issue in a test project, I'll see if I can do that, I do have a dropbox, so sharing the entire project would be possible - that would be what makes sense, right?

Yes. Maybe not necessary to include video at all. And if you have VP14, please upload in that format so we can open it in VP14 or 15.

I'll get back to this, got myself a chairman task in the housing coop and it "did things" to my schedule and still does with the role transfer logistics, anyway; this is not about the original audio file, it is about V15 fading it up after having faded it out, sometimes using a part from a random location in the file, so the original audiofile is not what it is about, it is what vegas does to it. And that changes randomly when the peak file is deleted and re-created. This project is very simple btw. - a few still images, a phone number overlay on a separate track, vox and music underlay. I have had the issue previously, this time I had to make an intermediary render to get the burp faded, other times just shortening the audio file removed the detectable problem, it may still have been there.

Sorry about the delay in responding, now I have a clean event of this to report as bugreport. The lowermost audio track is a render of the compound track above it. Vegas has seen fit to add what appears to be the beginning to the end.

i'm wondering if one of the clips has 'looping' enabled on its properties, and somehow, because the audio files are shorter than the length of the rendered video, it's 'looping' some of the audio...which might explain why the audio appears to restart from the beginning. Maybe try turning off 'looping' (right click audio file, uncheck 'looping' box)

i'm wondering if one of the clips has 'looping' enabled on its properties, and somehow, because the audio files are shorter than the length of the rendered video, it's 'looping' some of the audio...which might explain why the audio appears to restart from the beginning. Maybe try turning off 'looping' (right click audio file, uncheck 'looping' box)

No! - unwise looping default is disabled in preferences and I doublechecked before posting, I should have mentioned this, thank you for asking! - also btw. looping default or not, Vegas decided to make the file longer, it is a render to audio only of the above audio so that I could toss in some processing in my preferred audio editor and thus should have exactly the same length. The displayed extra audio is not a part of the file, it is something Vegas has found in the file and repeated. Wonderfully simpler the way it happened this time.

No advice, but it does appear to be doing an "autofill" with the audio. That is a strange one.

Here is another example, sorry about the misinformation, I overlooked that the rendered audio file has the length of the project but it should be silent at the end and not have that audioburp ...

well I'm stumped. But I'd be curious if somebody else has the same issue with your project. If you get to the point where you can post the entire project, please do so and we'll give it a go to see if the issue appears on another person's system.

About the only thing I can think of is to transcode any lossy audio file types (especially MP3) to PCM <48kHz .wav> using Sound Forge or another audio editing app.

Unless there's a looped hidden take you have not noticed. Look in 'Project media' and/or have 'Active take info' enabled, You probably checked this already though.

About the only thing I can think of is to transcode any lossy audio file types (especially MP3) to PCM <48kHz .wav> using Sound Forge or another audio editing app.

This is a simple "highlights" edit of some files from a one camera recording, so yes, they audio is lossy encoded into the files. The audio this happens with is the re-imported processed audio, differences are visually obvious.

Unless there's a looped hidden take you have not noticed. Look in 'Project media' and/or have 'Active take info' enabled, You probably checked this already though.

Again, as stated above the looping default is disabled in preferences. I do not quite understand the rationale for its enabling out of the shrink wrap. And yes, as stated above I have checked that it is Indeed disabled.

This is not a first time occurence,  and as I mostly work with audio recorded as audio on an audio recorder I generally do use separately imported audio in a production flow that keeps it well clear of lossy destruction until final render. It took a bit of strategy thinking to get there, but it is well worth it, also when you use camera audio that is recorded as embedded acs, do not re-encode if you process it separately.

Thank you for caring, it may well be that it is a bug with audio imported into a project as .wav, I haven't thought if it but just always end up doing it because I tend to work with music and concert documentation.