Seperate stems don't work

[jabe]

The fact that the progress bars went all the way suggests it's something happening at the end, rather than during the splitting of the data. The obvious thing would be the failure to write the split stem files to the Rendered folder. But why?

I have an idea, but I need to rewind my brain by a decade or two. This may take some time (and a sleep)...

...right, this might help.

Some years ago a chap called Mark Russinovich wrote a number of very useful utility programs for use to help investigate and fix Windows-related problems. He made them available to others. Eventually Microsoft signed him up and he now maintains them for Microsoft. The programs go under the collective title of Sysinternals. We'll use one and see if it can help.

I want you to download a file called ProcMon64.exe from here: https://learn.microsoft.com/en-us/sysin ... ds/procmon
It is possible to run it from Sysinternals.live, but I've not tried that.

When you start ProcMon64 running (double-click on the file to start it), it gives you a torrent of information about what is going on on your computer.

Click Menu option Filter and then the Filter option with the funnel icon against it. This allows you to limit what you see by specifying values for any of the column headings. Set it so that it only includes data for lines where Process Name is Waveform 12 (64-bit).exe

You could also get it to Include lines where the Path contains the word Rendered. This will save time later.

Click the File menu option and then Capture Events to stop it capturing events.
Click the Edit menu option and Clear Display.

Start Waveform and set a stem separation running

You can afford to wait a few minutes at this point.

When the progress bar shows the splitting is moving along, go back to ProcMon64 and under the File menu option click Capture Events.

When the stem splitting completes, give it a minute or so and click Capture Events to stop it doing so.

What we are looking for are the lines where attempts to write the stem separation files to the Rendered folder happen. If they actually do happen.

At this point, I should mention that Save under File allows you to write the whole current display to a file. But we can give that a miss for now.

To find the lines we are interested in, you can search for the Rendered folder (I wrote the bit above about only showing lines with Rendered as part of the path was written after this bit). Some of the searches are slow because there are many lines of data to check. The method I found quickest is to go back to the Filter and add a condition to only Include lines where the Path contains Rendered. Apply that and the number of lines drops quickly and massively. In my case, it reduced two million lines to just 658.

The lines you are left with may (fingers crossed) contain lines where attempts were made to write files in the Rendered folder. On mine, the majority of lines have SUCCESS under the Result header. The operation column shows what sort of file access was attempted. See if you can find any lines where an attempto to write a file (or to a file) has failed, and paste a screen shot or similar on here.

Fingers crossed. Good luck.

[brianmi40]

Thanks tremendously jabe, was able to install and capture. Reminds me of some basic network sniffing I did back in the day.

First off, noted several Access Denied entries, so changed Waveform over to run with Admin rights. Afterwards still getting the Stem Separation fatal error, and capturing seems to show more Success, but a few Name Not Found. I tried importing the MP3 into the folder when adding to the Track in case that was the issue, even named the track from a default number.

With Procmon filtering in place to:
1. Operation = CreateFile
2. Path [contains] Stem Separation
I get 5 rows of Success, but they are all for "demucs_tracktion.bat" which seems to me like batch files they create to process each of the 4 stems and then perhaps one to move them all to Rendered? Found that batch file and its about 15 lines of passing parameters to Python ostensibly to run the audio separation algorithm.

To minimize clutter since just switching back to Waveform triggers a host of entries, I found I could request the Separation then Clear Procmon, then kickoff the Separation. So, Removing the Path filter and running the Separation, I get a first two rows in Procmon as:
1. ...AppData\Local\Temp\temp_8e568aa7.wav NAME NOT FOUND
2. ...AppData\Local\Temp\temp_8e568aa7.wav SUCCESS
So it's interesting that the same filename gets a Name Not Found immediately followed by a Success. However, there are no .WAV files in that folder, so presumably it deletes them after the subsequent failure to write them to Rendered project folder?

It seems to me that CreateFile is not strictly for writing files, as there are a number of entries with it showing VST3 access for my plugins, which surely it's not writing to, but rather opening for Read access.

Switching #2 filter to be instead Path [contains] wav, to try and find the temp .wav file writes, I see 4 concerning lines of Name Not Found:
1. Program FIles\Tracktion\Waveform 12\Wmvcore.dll
2. Program FIles\Tracktion\Waveform 12\WMASF.DLL
3. Program FIles\Tracktion\Waveform 12\mfcore.dll
4. Program FIles\Tracktion\Waveform 12\mfcore.dll (clearly a repeat)

If you have those files as part of your installation, that may be the issue. I installed Waveform Free on another PC and don't see those, but perhaps they are only part of the Pro edition.

Adding "wav" to the filtering has the undesired side affect of picking up all references to the WAVeform directory... However, early on in the listing there are 4 entries for ...\Temp\temp_4793aa72.wav that appear in a row with Success shown, so those may be just empty placeholders, or actually containing stems, no way to know as the error message seems to clean them up so that I can't find them after.

Besides those, there are a couple ".adf" files that get Name Not Found. But a ton of ".ogg" compressed audio files all with Success marked.

That's all that stands out to me, perhaps you can suggest a further test or filter. thanks again.

[brianmi40]

p.s. forgot to mention that with "path [contains] Rendered" as even a lone filter, no rows show up.

[jabe]

Thanks for trying it out. Handy that you've some experience messing about in the depths. I'll give what you've written a more thorough read later and probably do another run. I am most concerned about the Access Denied messages, athough the SUCCESS response after the FILE NOT FOUND one is weird, especially with the files not being there when you looked in the folder. It may have cleared any debris out after failing, but, if if did, there should be delete messages for those files showing up later.

There used to be a Sysinternals utility called FileMon, but they say they've incorporated its actions into ProcMon.

You could try .wav instead of WAV. Might cut down on ones shown because of Waveform.

A couple of things I should have mentioned from when I was trying it out:

1. The NAME NOT FOUND message is not important. It checks to see if the file exists before writing it. At one point I had five sets of rendered files, all from the same clip, and each set had different names, and the four files had mostly similar names but with (drums) or (other) or (vocals) or( bass) in brackets to distinguish them.

This perhaps needs a line for anyone venturing hereabouts in the future:
YOU DON'T NEED TO CLEAR PREVIOUS STEM SPLIT FILES FROM THE RENDERED FOLDER BEFORE DOING FURTHER STEM SPLITS.

2. I had absolutely masses of checks of VST files. It seemed to go through everything a number of times.

(There might be other things I remember later).


Not going to get chance to look again today, I'm afraid.

[brianmi40]

Thanks again jabe, enjoy your New Year celebration! Off to the fireworks in a bit myself with my son.

I pride myself on using good query terms, so disappointed I didn't realize myself your suggestion to make it ".wav" to increase uniqueness. Also makes sense that they would check for the existence of a file before writing so that clears up the confusion a bit. Perhaps that is also what's happening with the VSTs, just checking to know which are indeed present to set some internal flags. Since it's a handled exception the programmer (or his C++ library used for the separation function) happened to have coded for, rather than a crash, I'm not surprised it cleans up the temp files. All of this is triggering some dormant brain cells, so had the idea to ask Perplexity AI (my go to AI Chrome Add in) if there's a log file for Waveform and since it said there is (Help Menu) I took a peek to see what it might have to share with us. No help as it only logs major program load and shutdown steps. Makes me wonder if there's a command line switch to run Waveform with verbose logging as some do. Perplexity was unaware, so would need a Dev to reveal that if there is.
Will have another go at some Procmon captures, perhaps the light of a new year can shed some insight tomorrow.
thanks again.

[brianmi40]

HAPPY to report this has been resolved, though I can't say clearly why.

Needing to step away from the problem and get my new build progressing, I decided to start installing the huge list of VSTs that I have on to the new build. This included putting on 2 USB external SSD drives (one for all Native Instruments Komplete as well as a ton of Kontakt content from 8Dio and others, and then another drive for all other VSTs, Loops, tools, etc.). This involved some drive letter changes, as I wanted to use F: and G:, so that I can grab and go with these two external SSDs to use mobile on my laptop, since everything would be mapped the same and simply have all my capabilities and projects readily mobile. So, I move Google Drive to H: and then set the F: and G: drive assignments and set about downloading and installing a boatload of VSTs from my fav places like Pluginboutique.

About 15 VSTs later, and opening and closing Waveform to test if they were working, and while watching a video on another monitor, it occurred to me that perhaps the process would be slowed enough by the video playing, that I could actually monitor the temp directory and see if the .WAV files show up there at all, even if just an empty place holder.

Sure enough, to my amazement, one did, and I was able to quickly copy it to see if I could have a listen even if the original was cleaned up by the stem split code. But, to even greater amazement, Waveform proceeded to COMPLETE THE STEM SPLIT and gave me the 4 stem tracks in Waveform!!

Thinking about it afterward, I can't really put my finger on anything definitive I did that would trigger this. It literally was some drive additions, drive letter assignment changes, including Google Drive, then some VST installs, and lastly re-scans of VSTs by Waveform.

Regardless, I was able to split multiple tracks and was happy to see the quality roughly similar to Moises.AI, albeit there for a few bucks monthly you can get 2 more stems. But for my purposes of breaking apart some songs that I want to make covers of, it lets me get the drum and bass out to stems for easier recreation and I can use Melodyne or Anthem Score to have a pass at the melodic or harmonic elements also.

So, thanks to jabe, talby and dysjoint for the help and tips along the way! Happy New Year all!

[jabe]

Splendid news. And happy new year to you too.

If future users arrive on this thread with the same problem, I'm prepared to compare results with them using ProcMon again to see if we can nail the problem.

[Peter Widdicombe]

Just curious - has anyone tried disabling OneDrive replication temporarily during the STEM process?