Looking to encrypt/decrypt external wavs in my sampler

I have looked around the forum and most threads just discuss which algorithms to use like XOR or RSA. But I need to know which method to override to intercept a file being loaded and decrypt it before it gets sent to the reader. I’m guessing it’s in the juce::File class since I’m loading my samples in like:

File* file = new File(note_resource);
ScopedPointer<AudioFormatReader> reader = audioFormatManager.createReaderFor(*file);

So I plan on making my own File class, I was wondering if anyone with experience with this or anything similar has any advice on which method I should override

I would suggest to inherit an InputStream and OutputStream. You can give them to any AudioFormatReader, and you have all freedom, if you get your encrypted data from a File, a MemoryBlock, or anything, even from a GZIPDecompressorInputStream…

You need to implement only 5 methods:
virtual int64 getTotalLength ()
virtual bool isExhausted ()
virtual int read (void *destBuffer, int maxBytesToRead)
virtual int64 getPosition ()
virtual bool setPosition (int64 newPosition)

Looks like only the read is specific to your problem…

1 Like

I wrote that as a POC, using XOR it works already (rather obfuscation than cryptography, but saves the CPU, RSA for wavs on the fly is probably a bad idea).
It looks like:

What I realised, it would be great to use a SIMD instruction instead.

JUCE Team: is it simple to add XOR to the FloatVectorOperations?
Is it naive to think, it is just a copy/paste job for
FloatVectorOperations::multiply (dest, src, num); ?

Cheers!

1 Like

Well, it’s not too hard to add, but wouldn’t want to put it into Float VectorOperations as it’s an integer thing.

TBH in a simple loop like that I’d be amazed if the compiler didn’t already manage to vectorise it properly.

Hah, true indeed… but starting a new class for that…?

I think so too, that the optimiser should do already a fairly good job. But to quote a wise guy: “Only believe what you measured yourself” :wink:

@daniel @jules Is the method discussed in this thread also compatible with the MemoryMappedAudioFormatReader? My app sometimes makes use of very large wave files so memory mapping is critical for performance. My dream is to have a modified version of wave format that is encrypted and that can be used in conjunction with memory mapped files.

I’ve now tried this. It doesn’t seem like @daniel’s suggestion of overriding InputStream works with MemoryMappedAudioFormatReader. MemoryMappedAudioFormatReader does its own File I/O and refuses to accept an outside stream as its source of data. :frowning: Too bad, it seemed like such a nice, clean approach.