Hi Martin,
Yes, I listened to the file you sent me. It is the file my Cubase points to, not the one I would expect. It is the incorrect file.
Best,
Magnus
Hi,
Then Cubase definitely exchanged these 2 files. Is there any relation between the files? Do they share same location, same name, something in common?
1 Like
Hi Martin,
I will look into this and report back, but I may not be able to do so until tomorrow. Anyway, I am beginning to suspect that perhaps either Spectralayers saves out wav files by giving them the same names - thus overwriting old ones - or that Cubase has done something similar.
I will take a close look at the two corrupted cprs etc.
All the best, and many many thanks for your patient help,
Magnus
Hi again, Martin,
I have started checking up on your suggestions above. The two corrupted cprs (playing the wrong Spectralayered wav file) were created and finalised for mixes on the following dates
- 22-24 February
- 16-22 March
The cpr to which the incorrectly played vocal wav file belongs was created and finalised on 27 March, i.e. after I had created, finalised and mixed both the now corrupted cprs.
All three of these cprs reside in separate folders, not together with each other. However, all wav files created by Spectralayers are by default stored in one and the same folder on c.
The screen shot below from the folder where Spectralayers by default stores its exported wav files, shows that the file in question (Vocals (2028).wav) was created on 22 February, i.e. the same day I started working on the first of the now corrupted cprs. It also shows that the file was modified on 27 March, i.e. long after I had stopped working on this cpr, but the very same day that I started working on the cpr to which the vocals now incorrectly pointed to in the corrupted cprs actually belongā¦
It seems to me then, that either Spectralyers or Cubase may have overwritten this wav file when I worked on the cpr created 27 March.
By default, Spectralayers stores all exported wav files in the same location. Could this be a clue to the issue? Also, I have no idea how Spectralayers autonames its wav files, but as the screenshot suggests it seems to number them - and there is at least on Drum wav file in the screen shot with the same number as the Vocals file in question - 2028. Perhaps this is not significant, what do I knowā¦
Please let me know if you need any more information from me.
All the best,
Magnus
Hi Martin,
Any progress based on my information above? I am still hoping for a solution, or at least an understanding of what has happened so this can be avoided in the future.
All the best,
Magnus
Hi,
Iām sorry, I donāt know the SpectraLayersā storing (and file naming) mechanism. I even donāt know, what the *.gpk file means and what is it good for.
In any case, if the problematic file is in this SpectraLayers folder, my guess is, SpectraLayers did something wrong, not Cubase. Cubase is storing the file to other location.
With these informations, you collected, I would probably try to reopen the discussion in the other (SpectraLayers) thread.
Hi Martin,
Thanks for the verdict. I will report back to Robin Lobel in the Spectralayers forum - he is the developer. However, seeing that both Spectralayers and Cubase Pro are Steinberg products, and in fact also integrated with each other, I would have thought that Steinberg support might take a more integrated approach in issues like this. Perhaps you and Robin could take a look together?
.gpk files are the graphics files generated by Wavelab. I opened the offending wav in Wavelab at one point to see if it looked alright.
All the best, and thanks for your kind help so far. I am still waiting for a solution, though. 
Best,
Magnus
Hi,
Neither Robin nor me are Steinberg support.
There is no deep integration. SpectraLayers is an ARA plug-in. So the integration is on the very same level, as other ARA plug-ins, for example Melodyne. SpectraLayers is not part of Cubase code-wise at all.
Hi again, Martin,
Sorry, my bad, I actually did think you were a Steinberg employee. I am very grateful for your help - even more so now. Still, I do think that Steinberg support should take an integrated approach to the Cubase/Spectralayers combo, not least since a scaled down version of Spectralayers is part of Cubase 11.
From a user perspective, it is quite irrelevant whether Spectralayers is part of Cubaseās code. It is marketed by Steinberg as a part of Cubase Pro, so I really think Steinberg should think again about how they approach this, and what this implies to their users.
Again, thank you so much for all your help. I hope now that Steinberg will do something about this issue.
All the best,
Magnus