For me it’s a little bit complicated question. I spent some hours in google, but don’t think that have any good results.
I have a plugin and I have a folder with wav samples for the plugin.
I don’t want to use it like a simple folder with a regular access for a user.
I’ve seen, that some plugins use tci format for the folders with samples. So I want to do something like that, but have no ideas how and how to use it with Juce.
Could you provide any ideas how to do something like that and implement with Juce?
If your samples are very small embedding in binary would be simplest.
It all depends what’s the rationale to “hide” the samples.
But basically you can do anything.
From a simple zip with a password and renamed extension to an encrypted file.
You didn’t mention how the samples are being used. If they’re loaded to memory at once or use some streaming or caching.
These are samples for a synth. And user can download different packs of the samples from the Internet. Then in pluging he just set a path to the folder with samples.
I just want to make an access to the wav files not so easy. Just to prevent reusing them somewhere else.
i think i would try to come up with a nice little encryption algorithm for the buffers that store the samples’ sampledata. so the samples get converted to actual sample data only when the plugin is used
I think that I had to write that the folder with the samples contains additional files like xml with additional information for the plugin, pictures of the instruments, etc. So it’s not only wav files.
As I wrote before, I’ve seen that some guys use tci extension for that kind of purposes. So users can’t simply open the folder and check all of these files. But I have no ideas how to use it (or something like that) with JUCE.
.tci files are probably a proprietary file format.
You will most likely have to implement some custom format yourself if you want to have samples + images + XML metadata hidden/obfuscated from users.
I personally wouldn’t bother with anything too complicated, something simple and lightweight is the best option, because someone who is determined could easily undo your obfuscation (unless you’re going with the serious copy protection options available, it will be more or less trivial for hackers to get your noise file or some other key used to extract the samples from your plugin), but it would at least stop casual re-use of your data.
The question really to ask yourself: is all this effort worthwhile? Much like copy protection, my opinion is don’t bother wasting huge amounts of time trying to be clever, because there are other people just as clever, or more so, who will shit all over your “clever” protection in no time at all. Better to spend your time creating cool software, and just add minimal protection that stops the casual sharing of your creations.
this is how i feel about it too. even about copy protection in general. people who wanna be legit will pay anyway and everyone else will find a crack anyway. so it doesn’t matter and is just a waste of time.
This seems like a good approach. When you say “make sure that your wave file accepts values over 1.0f” do you mean that the wave files must be in 32-bit format?