It would be wonderful if Audacity had the ability to read (and write) the smpl chunk for loop points and cue chunk for markers in wav files. Of course basic editing, like moving them, deleting them or adding them is needed. Both smpl and cue chunks are part of the wav standard and it would be great if Audacity could handle them and not remove them as it currently does.
There are other programs for automatic loop detection so that’s not at all necessary, but many times one need to for instance recut a sample or edit it in another way while one wants to keep the loop and cue markers intact.
It would be great for Audacity if we got the loop points and marker points active if we wanted to !
I’m using Audacity mainly for creating virtual instrument’s dounds using wavs ect, and looping and marking is essential, so after work with Audacity I always have to use another two apps for comletion… The best will be, after I got my wav file, to work exclusively with Audacity…
Very good and helpful program though. Also great mp3 export and mpeg4 to mp3… !
I’m in for this proposal, Larpal, good you pointed out !
I agree, if Audacity had the ability to see/keep and create loop markers and release markers then it would become the tool of choice for creating sample based soundfonts (for Fluidsynth), organ sample sets (for GrandOrgue), orchestral instrument sample sets in GIG and SFZ formats (for LinuxSampler). All these opensource sample playing apps would benefit greatly by having an opensource based wave editor able to handle all of the work required in making the sample playable.
Is there a feature request list that we could add this too?
As Larpal has indicated, these functions are part of the WAVE standard, so it should be relatively easy to find the definitions and create the code routines that would handle them.
As a user and not a programmer, I can only offer to help test
Although the Microsoft WAV format allows the “smpl” chunk (“cue” points are included in the “smpl” chunk), it does not define exactly what data is written there. The MIDI Manufacturer’s Association (MMA) allocates ID numbers to manufacturers who then have certain flexibility as to what data they include. This can lead to incompatibility between WAV loop files from different manufacturers. For example, Acid Loops and Apple Loops are significantly different, and unless an application specifically includes importers to handle these types they will not be interchangeable.
The smpl chunk is an optional data chunk that allows manufacturers to add custom data to suit their products and only some of the smpl data is standardised across the board. The only guaranteed way to correctly handle the loop data for specific hardware/software is to use the manufacturers loop editing tools. Adding partial support (just the common/standardised parts of the smpl chunk) would require a great deal of development work, and would still leave many users unhappy because of the unsupported features.
Addressing specific points:
For FluidSynth and other SoundFonts, there are specialist programs for dealing with this format, for example “Vienna” on Windows or Swami on Linux.
For proprietary formats such as GigaSampler, Sony Acid, Apple Loops, and so on, each manufacturer provides software to fully support their format. As an open source program it is quite likely that Audacity would run into licensing problems if it attempted to implement some of these formats.
If a loop sample is edited, it would not be sufficient for Audacity to simply retain the existing smpl data, as the editing is likely to make that data incorrect. For example, if the loop points are defined relative to the start of the sample, then changing the start point of the file will cause all loop data to reference the wrong positions, and may reference invalid positions beyond the end of the file. It would be necessary for Audacity to recalculate the smpl data, which means that it would need to understand the exact format used in the smpl chunk by each manufacturer. Manufacturers may also use data that is specific to specific samplers, which would make error checking of the data a total nightmare.
Yes, of course the loop points and markers must internally be stored as to exactly what sample (wave data) that they refer to. So that if one cuts away part of the beginning or end, the loop (or marker) should still be on exactly the same samples as before the cut even if the samples themselves are in a different position in the file.
This is likely well known but the wave specification and the updated standard from Microsoft can for instance be found at http://www-mmsp.ece.mcgill.ca/documents/audioformats/wave/wave.htm. The smpl section is on page 16 and the cue section at the end of 12 of the updated document.
And yes, the markers in the cue chunk is also important for samplers. In GrandOrgue for instance they are used to determine the release of the sample.
Other third party versions of the loops and cue markers are not so interesting, but those that are specified in the wave standard really should be implemented. It’s so sad that one must use closed source software for something that’s so basic as modifying/editing audio samples that are intended for open source software.
There’s certainly some amount of coding work to implement this, but perhaps a glance at the source files of GrandOrgue http://sourceforge.net/projects/ourorgan/ that deal with the wave loading could be helpful. Mainly it’s the GOrgueWaveTypes.h, GOrgueWave.h and GOrgueWave.cpp in the trunk that could be interesting.
I really hope that I someday can use Audacity as my main (and only) audio editor, but until this is implemented I’m forced to use other software that I’d rather not use if I had a working alternative.
Actually, after quickly browsing through the libsndfile source, it seems that the mechanisms for reading and writing the loops and cues already are in place! It’s not immediately obvious how to access the features as they appear rather private, but they seem to be there alright.
So, basically one would need to find out how to read and write that information through libsndfile (when opening/importing or writing/exporting a file) and then add some classes that can draw and handle the loops and markers connected to the sound file internally in Audacity itself.
Do you know if it would be possible to handle that through a “Module”?
(see also: http://wiki.audacityteam.org/wiki/Scripting_Module )
(sorry, I’m not a programmer, but perhaps one of the guys from the GrandOrgue project would know).
If the feature could be developed as a module, then that would be the fastest way to add the feature to Audacity. In the run-up to Audacity version 2 there are no new features being added, but that does not apply to Modules. Modules do not interfere with the core code so there is no chance of introducing new bugs at a time when the developers are working to eliminate them.
But, I’ve experimented with libsndfile a little and so far I’ve verified that it’s possible to at least read all the necessary information from a file with the library. The loops are pretty easy to handle as there are special structs and function calls to use, with the cue markers the situation is worse as they (as far as I can tell at the moment) can only be read through the log info. (unless the library in itself isn’t modified/expanded of course, which would be a pretty easy thing to do)
I’ll have to do some more research, and also learn more about this Module (scripting feature) that you mentioned… Thanks for the information!
In theory, the mentioned features really shouldn’t be so difficult to add. But it could also be my limited understanding and naive attitude talking!
I’ve finally managed to understand how libsndfile works with the loop points and also modified the library so that cue markers can be handled and exported to wav files. This feature of libsndfile I’ve posted back to the original author with a feature request to add it to the library.
After some thoughts about how to implement this in Audacity I think that reusing the labels (labeltrack) already present would be a possible alternative. Basically one would create new classes for loops and cues that can be used as labels (loops or cues created from labels, or labels created from the imported files loops and cues) and exported to wavs.
Something like this screenshot would be very nice in my opinion.
Kind regards
With this approach, the key issue is to update the libsndfile like I’ve done locally so that it handles the cue points. Then it’s actually only required to adjust the import pcm and export pcm source files in Audacity so that there’s a check for if a .wav file have loops and/or cues in it and from them create a labeltrack (which really only requires a few lines of code). For the export one just check if there’s any labels and transform sections into loops and single markers into cues (also only a few lines necessary to add). Audacity already have very nice handling of the labels themselves with the ability to sync it to a wav track and snap it to samples which allows for very exact adjustments.
I’ll try to create a test build in a few days to see if I can get it to work. If it’s successful then one should perhaps wait until the original author of libsndfile approves of the changes before suggesting the small changes to the Audacity devs. But if I’m successful in getting it to build I can post the steps necessary for others that are interested in having this feature in a free and open source audio editor even before it’s officially approved!
Another update. I’ve managed to implement this idea! But since I’m not experienced as a programmer, everyone should be warned about the possibility of errors in the code I’ve added. All my changes should be reviewed by someone competent. Please try it out, but it’s on your own risk…
I’ve done all development on a Ubuntu 11.04 (32 bit) computer. I compiled the wxWidgets myself, but I only managed to get Audacity to compile if I used the unicode version of wx. The version of wx that’s in the repositiories should work also.
The steps to create a loop/cue aware Audacity build are:
Get the source code for Audacity (with subversion)
Install all dependencies and tools for building Audacity
Exchange some files in libsndfile folder (AudacityFolder/lib-src/libsndfile/src) that I’ve modified so that cue markers can be handled with libsndfile
Exchange the AudacityFolder/src/export/ExportPCM.cpp to my version
Exchange the AudacityFolder/src/import/ImportPCM.cpp to my version
Configure Audacity to use local libsndfile (I used a line like ./configure --prefix=/home/lars/audacity --with-libsndfile=local --with-libsamplerate --with-libid3=no --with-ffmpeg=no but you can modify it to suit your needs)
execute make and make install (since I used the prefix in the configure I don’t have to use sudo make install and since this is a highly experimental build…)
The files in the attached archive changedSRC.tar.bz2 should to into libsndfile/src, and the textfiles should loose the .txt suffix and go into respective folder as indicated above.
When I use this feature I always sync/lock the tracks and set the snap to samples in Audacity.
Again, be warned that you try this on your own risk! It works for me and it would be great to hear what others think. What’s nice is that one can handle up to 15 loops in one wav and up to 10 cue markers (due to current limitations in libsndfile). This is still much better than many other audio editors. Wavosaur for instance can only have one loop. Audacity is a really fantastic piece of software!
I’ve got some really good news! I’ve been in contact with the author of libsndfile (Erik de Castro Lopo) and he said that the cue feature will stand a very good chance of being included in a new libsndfile release! Actually, it’s likely that not only wavs will have cue support but also aiff files and their number can easily be increased.
If this feature eventually will make it’s way into Audacity (which I really hope it does!) it’s possible that it could be activated/deactivated by user choice and not forced upon like my hackish implementation presented above. Anyway, this would really stand out as a remarkable feature in an open source audio editor!
I usually don’t like to add to two years old posts but I thought I’d better update this thread in that as far as I can tell, sndfile-convert in libsdfile 1.0.25 (current latest version) discards the cue chunk at the end of a WAV file (and accordingly, so does Audacity when it exports).
However sndfile-info appears to see and understand the cues.
Has anyone recently (or ever) tried out Lars’ changes?
It is not really a patch yet (a “patch” would be a file listing differences between the current code and the new code), but the instructions and the changed files are above. You would download the current Audacity source, replace the files indicated, then recompile Audacity.
This may no longer work now, because other code has changed.
