Home → Audio File Formats → ReCycle & Propellerheads → So what's up with support for ReCycle formats?

2.1. So what's up with support for ReCycle formats?

Well, it's a funny story.

The ReCycle format was one of the first (and therefore most important) to support a new kind of label: slices. They weren't markers, they were simply points at which a sample engine would be able to play back from based on a MIDI note or a time base or something like that. It was a great idea, and it's carried on through the ages.

In order to support this new "slice" idea, Propellerheads needed to make a new audio file format to hold it. They started out by extending the AIFF specification and adding a new chunk of their own that would describe the tempo, bars & beats, time signature and slice points. This was called the .rex file, though it was essentially an extended AIFF format. This was all well and good, but moderately incomplete - and Propellerheads left no documentation as to what these extensions to the AIFF format were, so developers like ourselves needed to reverse-engineer the chunk. This wasn't too hard, but it left some unanswered questions and some unsolved glitches, to which Propellerheads to this day has not answered.

Propellerheads soon went further with the .rcy format, which was *similar* to the .rex format, but was more mature in the sense that there were settings for sensitivity for each slice, and other technical things. For some reason it didn't catch on quite as well, but you can still see it around today. Again, Propellerheads published nothing about the format, reverse-engineering wasn't too hard (but still questions remained), and it was still an extension to the AIFF format.

Being extensions to the AIFF format made it possible to make changes to the audio and to make changes to the metadata - including the custom ReCycle chunks, provided you guessed well in your reverse-engineering. We had done a pretty good job on that for some time, and things seemed weird, but *ok*.

Perhaps around this time Propellerheads decided they would take things even further. They decided that the proper way to read any ReCycle-formatted AIFF would be to read it through their "ReCycle Shared Library", which would interpret the formats properly and give any developer the ability to read a ReCycle file without any misunderstandings - but not to author one. This way, no matter if you were reading a .rex or a .rcy file, running it through their library was the sure-fire way to make sure you were getting the info (tempo, bars/beats, slices, etc) properly. However - this left the answer of how to *write* a ReCycle-formatted file even more murky, as the ReCycle Shared Library included NO way to author or make changes to a ReCycle-formatted file. Apparently their application "ReCycle" was the only one that was going to be able to do this.

Soon after, it became clear why they were doing this. They released the .rx2 format, which was fully encrypted, audio and all. It wasn't an AIFF file - in fact it was their own format with their own compression that was ONLY readable through the ReCycle Shared Library. The reasoning? ReCycle 2.0 included things like effects and compression that they wanted to keep consistent throughout various playback engines - this way if a developer read a ReCycle file through the shared library, you would be SURE to get the same sound and effects that it was originally made with - even though the playback engine itself might not HAVE those same effects. Interesting idea, which was taken *even further* by *compressing the audio itself*, left totally un-reverse-engineerable. NOW one couldn't even READ a ReCycle file, much less WRITE one, without the ReCycle Shared Library.

So, in order to read any ReCycle formatted file properly, the ReCycle Shared Library is necessary.
The shared library has no means to *author* a file or to make any changes to a file. Only their application ReCycle is able to do that.

Our philosophy at Audiofile is to give the user the most and best control of the audio as possible. If we were to read in ReCycle formats in their proper format, we wouldn't be able to save any changes - you'd be forced to save as another format, which might upset people who didn't know that that's what they'd have to do in the first place.

This is why we consider the ReCycle format a "foreign" format and can only IMPORT it - this way it's already a new file, heard properly, and obvious that it must be saved in a new format if changes are made.

We read all the audio and metadata that is possible to be read from the ReCycle format, slices and all. We are still having SOME issues with the placement of particular slices in particular situations, but we are working on those as we speak. All data can/will be saved in appropriate formats (.wedt can store it all, Apple Loops and ACID files can store most of it [the important stuff, anyway]).

We're doing the best we can, but to THIS DAY Propellerheads has not responded to our requests or questions regarding the ReCycle Shared Library, and we don't expect them to change their position on the matter.

This is why we are throwing more resources toward full support of un-encrypted slice-based formats such as Apple Loop and ACID. Though Apple has not given anyone the specifications for their extensions to the AIFF format which constitute the Apple Loop format, they are fairly easy to reverse-engineer and test. So far so good. Sony even got back to us with the specifications for their ACID extensions to the WAVE format, so we're in good shape there.

We believe that Propellerheads has painted themselves into a corner with the ReCycle format, however, they have such a strong product base in Reason that we're pretty sure they can strong-arm the ReCycle format for many more years.

So that's the story. We're doing the best we can.