I want to use my samples for a different platform that uses .wav files. Is there a Mac compatible conversion method?
What platform doesn’t recognise BFDLAC files?
Both Windows and Mac recognise .wav files as well as BFDLAC files
I want to be able to convert my BFD files to .wav format
That would be BFD.
BFDLAC is an unpublished, proprietary format. It’s not a generic audio compression algorothm, but one optimized for the special case with multichannel drums, where a huge percentage of the data is actually zeroes. AFAIK, the only software that knows how to convert to WAV is BFD itself.
I think I get what he’s asking now, when @JimG says, “different platform” he means other drums player or sampler?
Since BFD3 is the only software currently able to read the BFDLAC format ((AFIK) ) then only BFD3 would be able to convert them back to .wav format.
I thought the BFDLAC tool used to be able to do that but looking at it again it doesn’t look like it can.
So it looks like the answer to your question @JimG is no, they can’t be converted to .wav files.
Thanks for the kind help! I use a Zendrum with a Stompblock and wanted to import my BFD samples into it.
For performance, your best bet is going to be an instance of BFD running on a dedicated computer, as a MIDI slave to the controller. There’s someone on the board here working on a Raspberry PI implementation, which you might be able to mount in a small, rugged box with an SSD. I have no clue how well that works. But if it works out, BFD would be an unbelievable performance engine.
I had a whole setup with acoustic drum triggers on mesh head drums and an Alesis control unit. It sort of functioned, but was never good. It’s been a while, though.
I’m guessing the main idea for a proprietary system, is to prevent easily copying and sharing the samples? Slate drums has it’s own lossless format too.
Main idea? I don’t know about that. SKoT published some academic papers on the subject. BFDLAC was available for licensing by ROLI. So, it’s not like they were trying to keep it a secret. It was a substantial improvement that required academic development, and they wanted to profit from it.
The storage savings are substantial just by the elimination of zero data. This also improves the engine by not burdening the CPU with rendering of zero data. Also, most drum information is in the transient and down close to the noise floor. There’s less information in the sound of a drum head. The algorithm is optimized to reflect that.
There are other optimizations, too. For instance, compression time needn’t be considered at all, compared to rendering time, which is critical for an engine. There are multiple compression algorithms within the CODEC. The most optimal is chosen for use within a sample.
Through a lot of the history of BFD (and drum software in general), there was often a good amount of tweakage necessary to get the engine to work on a particular CPU and storage combination. The number of engine parameters in the Preferences are evidence of that, even though it’s been unnecessary to touch them for years. I think drums in particular have performance requirements that suit a more nuanced approach than your generic sample library.
On Mac it would be the easiest to use Autosampler (included in Logic and Mainstage).
I wasn’t necessarily referring to lossless encoders, but samplers using proprietary audio file formats, rather than say .wav files to make it harder to copy/steal/share, etc.
Well, I don’t know about motivations. I’d say there have been some good technical reasons for doing it this way. It’s not the same thing as encryption. I’m sure if someone were hell bent, they could figure it out.
Our motivation for BFDLAC was to have more detailed libraries and get more bang for our gigabyte - something like Vintage Recording Techniques would require a dedicated hard-drive just for one pack if we didn’t have BFDLAC!