If anyone’s interested, I’ve just posted some code on the SVN tip that adds a few classes for generating audio thumbnails. I think people have asked about how to do this before, and any comments would be welcome!
Thank you thank you thank you thank you Julian.
Yesterday, I’ve played a bit with the new class and I think this is very handy class a lot of people were waiting for.
A small request. Sometimes, it’s very good to pass already opened AudioFormatReader to the class instead of InputSource. Can you provide an additional initialization method for this purpose? Of course, if you can duplicate an AudioFormatReader class instance.
One more. The building process is very CPU time consuming, so can you add something like Thread::sleep(20) to lower that?
Ok, I can add an extra method to take an audioformatreader.
Since the cache object is a thread, you could lower its priority to whatever level you need. That’d probably be a better fix than forcing it to sleep.
Ah, no - sorry, I forgot. It can’t use an audio reader, because it needs to have the ability to create and delete the stream itself whenever needs to. That’s why it uses the new InputSource class.
I’m also interested in the audio thumbnails.
For example, Apple’s Logic Pro asks users that whether the processing requires high CPU load or background when the audio thumbnail is being created. An alert dialog is shown and it has a toggle button to set the answer as default. (“Don’t show this alert next time”)
I think developers who use the JUCE’s thumbnail class wantto implement the similar thing.
would be cool if you can pass a priority flag to the constructor of the thumbnailer, in order to lower the overall cpu usage of the inner scan/calculation thread.
It’s only a case of calling setPriority() on your cache object when you create it.
There seems to be a bug in the audioThumbnail class (in the juce-tip). I was testing how long it would take to thumnail a aif file of a complete CD. Sometimes (after fullyLoaded == true) a call to drawChannel causes an acces violation. Before updating to the tip I used rev 406 and wasn’t able to thumnail aif files at all. The funny thing is that the bug only manifests itself in Windows XP, OS X doesn’t seem to suffer from it.
Also, why the need to delete the reader after a certain amount of time?
I checked in a new version a couple of days ago - you might want to try that. But if you can narrow down the bug, I’d love to know about it.
It releases the reader to avoid locking the file for longer than it needs it. I’ve fine-tuned this in the latest version too.
Yes, i’ve tried the new revision to no avail… The bug seems rather hard to reproduce, but mostly happens when using really long files (like an hour).
The bug manifests itself in the drawChannel function, just after this bit (line #517 of AudioThumbnail.cpp):
const char* cacheData = ((const char*) cachedLevels.getData())
+ (channelNum << 1)
+ skipLeft * (numChannelsCached << 1);
I doubt that it has anything to do with the variables I’m passing in
Oh yeah, it’s not just AIF files, but WAVs as well…
I can’t see any errors with that code, but have never tried it on a file that long (in fact, I don’t think I even have any files that long…)
Maybe a maths overflow? If you can catch it in the debugger, any numbers you can find would be helpful.