I found the real problem, (that explains a case browsing completely scanned folder without results): There was an invisible filter configured in the FileBrowser (here for MIDI Loops). I am currently investigating the root cause.
The issue can be surgically fixed by editing the Defaults.xml in a text editor (while Cubase is not running): There is an entry that stores the settings for the FileBrowser:
With the current implementation (based on sqlite?) this is not actually true.
“voidtools everything,” a freeware software download, finds all the wave files in my disk faster than a completely scanned Cubase browser. Totally without pre-indexing – it just reads the NTFS MFT directly. If you haven’t downloaded and tried this tool, I highly recommend it
It would not find the (user) attributes in the various supported chunks of the various media-types the MediaBay supports, e.g. the BWF Description in audio files, Rating, etc … in addition MediaBay is not bound to a file-system implementation. For searching in path and filename on NTFS, you are certainly right, while one could still regards the MFT as an index
It would not find the (user) attributes in the various supported chunks
That is technically a true statement, but if I want those, I’ll live with the media bay search time.
Meanwhile, because I search by name and path 90% of the time, I would like that to be fast. It is totally possible to make it fast.
Please make that fast, because that’s what I actually want to do! I don’t want to do the other thing.
Unfortunately, Cubase is a full-screen app (I mean, you can run it windowed, but that’s not the right way to do it,) so trying to use a third party tool as a file browser doesn’t work very well.
I’m mentioning this app, because it shows that finding files by name can be super fast. I want listing files within the file browser in Cubase to also be super fast.
In fact, I don’t even understand why it’s slower to search for attributes – it’s at most a few megabytes of data, ripping through that using linear search in memory should take a millisecond at most. All of the extra time comes from overhead that shouldn’t be there. Maybe it’s using sqlite, and maybe sqlite has all kinds of locking and indexing overhead, but managing 50,000 files with attributes as just flat records in memory is totally reasonable these days; chances are the entire database can just be replaced with a flat file and a flat vector and it’d be 100x faster with the same functionality.
Your thoughts are correct and challenging … Yes, there is overhead, but most overhead in the specific use case of a search is caused by other requirements: multi-threading, reader / writer starvation prevention, persistent scan progress (even when 3rd party codecs crash the app) … no hard limit on attributes, neither on entries: 50000 entries wasn’t an edge case, go for millions, consider 100+ attributes (with individual flags per attribute entry), indexing each would blow db size and write times, full normalisation is impossible (see sqlite max inner joins) … sorting by sqlite is unresponsive … SSDs did not exist … CPU was 32bit and memory limited, audio and video engine must not suffer … some client code, down to plugin and remote preset browsing, has to be supported “as is”, etc. …
Still we see potential for optimisation in terms of speed and resource consumption, reconsidering actual requirements. I am happily looking forward to spending time on that subject … if you like to discuss this topic further, please consider starting a new thread, we got so off-topic, sorry!
Doesn’t matter. This all trivially fits in RAM. This should be instant. They could build a full inverted index of trigrams and still fit it all in RAM, and respond in less than a frame of screen repaint.
Video games regularly queries databases of tens of thousands of objects and, these days, billions of polygons and texels, and render an updated view of the world 60-240 times a second. There’s zero technical reason for the Media Bay to have any perceptible latency in searching.
If anything – when it was first introduced, computers were slower, so it should have been optimized more back then, no? The fact that it’s still slow on modern systems just tells me “we shipped the prototype.”
Multi-threading, reader/writer, scan progress was a solved problem 30 years ago.
We shipped BeOS with multi-CPU support in … 1998? 25 years. It supported live file system queries at the time, and they were fast. Windows and macOS and even Linux have long since caught up with that, too.
The only reason Media Bay is slow, is that you haven’t actually spent the effort to make it fast. I look forward to an iteration where this is actually the goal! It could be great!
Certainly some wrong characters or broken commands.
You can indeed use a notepad and search for that line and you’ll find out what’s going on.
It’s better to fix it though, because if it’s broken somewhere, it won’t be able to proceed through the rest of the file. That’s why it refuses to load.
However don’t take my words for granted lol, maybe I’m wrong and Joerg will eventually enlighten us
Great to know the “Game Engine” will be rewritten.
The basic concept of XML: start-tag … end-tag should be understood when editing the defaults.xml … I wrote “surgical” because I (better) want a surgeon to cut my body open, he should know what he is doing
that comment! arrgh … can’t compete with GameEngines, unless we have the man power of a major game developer
I had exactly the same problem. I have Cubase 13 Pro, and everything was normal until I loaded my sample folder with new samples. Suddenly, I lost the audio files’ visibility in the Mediabay. Then, I realized that it reduced my storage space, and that was precisely what was causing the problem. I moved my folder to a new disk, freed up space on my main disk, opened Cubase, and the audio files were readable again, and everything was visible once more. I hope this helps
So is there a solution for this? I have some drum midi patterns that have been showing up just fine in the file browser- until about 2 hours ago. Now I see the folders, but no files. I’ve deleted the various .db files… tried rescanning in media bay etc…
Also deleted the ‘<string name=“Group” value="mediaBrowserMediaBay’ lines- no joy.
I get nothing in MediaBay, nothing in file browser. It does show wav files though in folders where they are located.
I’m using Cubase 13 pro (or I’d rather be than trying to fix this)
Hi @sheriff8 ! I was pointed towards your post by a colleague… (for all others waiting for some feedback from me, sorry I am currently in “focus mode”, will be back here as soon as time allows) …
Could you post or pm me the preferences of the Steinberg MediaBay Server folder and those of Cubase 13? I would look into the MediaBay state and see if I can quickly identify the problem & find a workaround.
Hi Joerg,
You’ll have to excuse my ignorance- where do I find those things? Is it the ‘mediabay3.db’ file? And ‘Defaults.xml’? BTW I reinstalled 12 on my other machine and it (bay and file browser) appears to work there… Tried same with 13 but still nothing.
Paul
