I just identified a bug which is pretty annoying for my workflow:
Create a project with an audio montage and a wav-file loaded
Save everything close Wavelab
Interchanged the wav-file with new content inside (e.g. I’m loading from an exported song from Cubase)
The filename of the song stayed the same but the content is now different (e.g. I made slight changes inside Cubase on some of my tracks)
Open Wavelab
Reload the same file(name) with the new content inside (even when clicking the refresh-button before doesn’t help!)
Load/Replace the file inside your audio montage.
You’ll discover that he is loading the old file with the old content even when the file-browser of Wavelab shows the new file (same filename) but with the updated time-stamp.
The only way to get rid of it, is to rename the filename and then load the file into the audio montage.
I’ve had problems like this too.
It seems to happen, when you activate to save a copy in the audio folder. As long as the name of the source file doesn’t change, Wavelab seems to look for the copy and decides: nothing to do, I already have it.
I tried to import files into a montage, where one was mono. This doesn’t work, but even converting the file to stereo (with the same name) didn’t help. The mono copy was already in the audio folder, so the error message reappeared.
The only explanation I see is that you have copied the file to the Montage folder when inserting the file (this is a WaveLab option). That is to say, the original file path is not used by WaveLab. Hence, if you replace this file, nothing will be changed in the audio montage.
No I’m not copying it from the montage folder. I’m draggin it from the filebrowser of Wavelab from the Cubase Mixdown folder. The first time it’s working. As soon as I change my mixdown (content) and I’ll click on refresh to see that it’s showing the file with the new timestamp but with the exact same filename and replace the old one in the montage container, it’s loading still the old file, even it doesn’t exist anymore. Neither in the filebrowser (because of the timestamp!) nor when I navigate to the location in windows explorer (Cubase project / mixdown folder). So it looks like Wavelab is using obviously some kind of cache file and it’s not really checking for a hash of the content. So this implies that you don’t use hashes to figure out if a file has been really changed or not. Could this be true?
WaveLab does not cache any file (unless decoded files such as mp3). WaveLab reads the files as provided by the operating system. The WaveLab file browser points to the files exposed by the operating system. WaveLab does not keep any file copy unless you edit the file. Therefore, this problem is to be searched elsewhere.
Is the updated file played correctly and only shown wrong (waveform), or does WaveLab still play the “old” file?
I somewhat remember a rare case, where WaveLab (version 12) would not show an updated file correctly (as it would not update the peak file). I don’t know the specifics anymore, there may have been multiple undos and redos and/or an application crash involved, still I think it played the file correctly as saved. And no, I was not using “Copy to Montage Folder” either.
I was thinking about something. Maybe you are on the Mac?
In that case, if a file is still open in WaveLab, WaveLab will not “see” that the file was indeed overwritten. I mean, macOS will expose only the old file to WaveLab, while this old file is overwritten from your point of view.
The solution is simply to close the WaveLab audio montage before you overwrite the audio file. If for any reason the file was copied to the clipboard, you will need to close WaveLab instead, before overwriting the file.
I have Microsoft Windows 11 running without OneDrive. I’m using Dropbox, but I’m not using the Dropbox related folders in the context of my whole production/mixing/mastering workflow.
@Simon_Millward found a way to reproduce the problem and I thanks him for this.
WaveLab has a mechanism to detect if the same file already exists in the audio montage folder. And if this is the case, WaveLab reuses the old file. But this mechanism has a bug in some case (also in WaveLab 12). I am pretty sure this is your case.
If this happens, a way to solve the problem is to delete this file while the audio montage is not open.
system.mon\file_imports.dat
What kind of update policy is this? It’s a bug and from my point of view a very bad bug, because it’s not in alignment with the workflow you would do especially when you are using Cubase and Wavelab in combination.
Wavelab 12 is a bit more than just 2 years old. Who did make this decision at Steinberg to shutdown updating bugs in at least the previous version too?
I’m a software developer too and especially when using Git/Github it’s so easy nowadays to take over bugfixes from one version to the other.
You should talk to the manager and tell them that that’s not a good customer policy. Especially when the update costs 99€ for Wavelab 12 users.
There are many different ways of using Cubase and WL12 in combination.
In your procedure, as described above, you could consider:
export the song you have changed using ‘Export Audio Mixdown’ to the Cubase Mixdown folder under a different name (with a new version number) and then use this to replace the file in the Wavelab montage.
OR
open the new file from the Cubase Mixdown folder in the Wavelab audio editor first and then save a copy under a different name, and then use this new file to replace the old file in the Wavelab montage.
In other words, change the name of the file. This would bypass the issue.
Either of these might be best practice anyway since you would be saving separate (hopefully consecutively numbered or dated) file versions for each change in the song. This would mean you would have the option to go back to a previous version if the latest version turned out to be not so good. It’s also best practice because it gives you recourse to backup files if something were to go wrong with the current file.
In other words, you might like to look at slightly modifying your workflow in order to simply avoid the bug. IMHO this might be the easiest and most pragmatic way to solve the issue. Or, if you are unwilling to do that, you do have the following way of solving the problem:
If this happens, a way to solve the problem is to delete this file while the audio montage is not open.
system.mon\file_imports.dat
Thanks a lot @stingray for this productive feedback. I’ll have a look into updating my workflow. Usually I change the version of my project whenever I’ve reached an important milestone. In this case where I ran into the bug, it was mainly when I didn’t reach a milestone but only made a minor change (e.g. forget to disable the limiter or slight volume changes).
