Howdy all,
I am working on the 3rd iteration of a long term project we use for sound spatialization at ZKM. The current sound server was built using Pd and runs internally using libpd.
We have many older projects which use CAF (Core Audio File) audio files (.caf or .caff) and I would need to be able to read them with Pd. I could find or make an external just for this file format, but I was thinking it could be generally useful to have this supported by [soundfiler], et al directly.
CAF specification: https://developer.apple.com/library/archive/documentation/MusicAudio/Referen... https://developer.apple.com/library/archive/documentation/MusicAudio/Reference/CAFSpec/CAF_spec/CAF_spec.html
The format is basically a container that takes different data formats, one being LPCM as in WAV & AIFF. We could post an error and ignore any compressed files. As the file structure is similar to WAV & AIFF, it seems like it wouldn't be too much work to add uncompressed CAF support to Pd and would work conceptually in the same manner.
CAF files offer a couple of advantages:
* 64-bit offsets for nigh-unrestricted durations (so file sizes > 4 GB) * recording could be faster as it allows for appending data * open format that is supported outside of macOS/iOS
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em qui, 18 de abr de 2019 às 06:02, Dan Wilcox danomatika@gmail.com escreveu:
I could find or make an external just for this file format, but I was thinking it could be generally useful to have this supported by [soundfiler], et al directly.
Sure, why not?
Moreover, I know I have a bunch of .caf files here from an Apple loops library, which leads me to yet another request. These loop files have information for a loop sustain region. Say you have a 3 seconds long sample and a looping region in between 1 and 2 seconds. Then you can have the file playing indefinitely until you release it. Of course this is also available for .aiff files. So yeah, this is more of yet another feature request, but I figure, if we're interested in updating [soundfiler] for this too, why not add yet more features?
I was once thinking about writing an external to extract loop regions as well, but you know my skills are poor, I don't know if I'll ever get there. This was in my wish list since I started working on cyclone, cause Max has this [info~] object that gets such loop information from .aiff files, for reference: https://docs.cycling74.com/max7/maxobject/info~
I already have an external in the ELSE library that uses loop regions to play sound files: [else/susloop~], but I still don't know of any way to get that information in Pd (I mean with externals, of course).
Anyway, I'm just gonna open a feature request for this on github.
cheers
“Why not?” would come from other maintainers who do not necessarily want to be stuck with yet more code. I’m pretty sure I can structure this in a way to fit in with the object already works, but I’d rather not try if there is no interest in recovering the code.
As for tagging info, it may not be too difficult to dump the extra info but that’s a separate issue.
enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com
On Apr 18, 2019, at 5:45 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qui, 18 de abr de 2019 às 06:02, Dan Wilcox danomatika@gmail.com escreveu: I could find or make an external just for this file format, but I was thinking it could be generally useful to have this supported by [soundfiler], et al directly.
Sure, why not?
Moreover, I know I have a bunch of .caf files here from an Apple loops library, which leads me to yet another request. These loop files have information for a loop sustain region. Say you have a 3 seconds long sample and a looping region in between 1 and 2 seconds. Then you can have the file playing indefinitely until you release it. Of course this is also available for .aiff files. So yeah, this is more of yet another feature request, but I figure, if we're interested in updating [soundfiler] for this too, why not add yet more features?
I was once thinking about writing an external to extract loop regions as well, but you know my skills are poor, I don't know if I'll ever get there. This was in my wish list since I started working on cyclone, cause Max has this [info~] object that gets such loop information from .aiff files, for reference: https://docs.cycling74.com/max7/maxobject/info~
I already have an external in the ELSE library that uses loop regions to play sound files: [else/susloop~], but I still don't know of any way to get that information in Pd (I mean with externals, of course).
Anyway, I'm just gonna open a feature request for this on github.
cheers
Em qui, 18 de abr de 2019 às 14:22, Dan Wilcox danomatika@gmail.com escreveu:
“Why not?” would come from other maintainers who do not necessarily want to be stuck with yet more code. I’m pretty sure I can structure this in a way to fit in with the object already works, but I’d rather not try if there is no interest in recovering the code.
Sure, I see. I hope then you can get it working in a way that doesn't raise any concern to Miller. I'll stress again that it can be useful at least for the loop and sound effects library from *Soundtrack Pro* and *Logic Studio* .
it may not be too difficult to dump the extra info but that’s a separate issue.
yeah, I had opened this one https://github.com/pure-data/pure-data/issues/586
cheers
I'm of two minds about this - I think it would be excellent to start offering 64-bit file lengths, but I wonder if this is going to be a widely-used format or not (personally I've never heard of it :)
Also - I have three dolist items for soundfiler/read/writesf~ :
fix thread-unsafe way readsf~ searches along the file path (need to make a local copy of the path so that the sub-thread isn't asking the canvas to do the search via open_via_path)
allow reading and writing ASCII text files (way way overdue!)
fix writesf~ to make running updates to the chunk size as the file grows, so that if the file never gets 'closed' it still gets a reasonable size
None of this is the least bit fun or interesting I'm afraid...
cheers Miller
On Thu, Apr 18, 2019 at 10:36:21PM -0300, Alexandre Torres Porres wrote:
Em qui, 18 de abr de 2019 ??s 14:22, Dan Wilcox danomatika@gmail.com escreveu:
???Why not???? would come from other maintainers who do not necessarily want to be stuck with yet more code. I???m pretty sure I can structure this in a way to fit in with the object already works, but I???d rather not try if there is no interest in recovering the code.
Sure, I see. I hope then you can get it working in a way that doesn't raise any concern to Miller. I'll stress again that it can be useful at least for the loop and sound effects library from *Soundtrack Pro* and *Logic Studio* .
it may not be too difficult to dump the extra info but that???s a separate issue.
yeah, I had opened this one https://github.com/pure-data/pure-data/issues/586
cheers
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
This is something that I could potential do at work and tackling that list could probably be part of it. I was thinking of making a generic interface so that file types could be split into separate .c files like the audio & midi backends. This would make adding a new format much easier and improve maintenance as well.
This is something that probably would happen more in late summer-fall time, although I could imagine doing smaller aspects of it beforehand for 0.50. I could justify using this time for the overall project, to some degree. :)
On Apr 19, 2019, at 6:35 PM, Miller Puckette msp@ucsd.edu wrote:
I'm of two minds about this - I think it would be excellent to start offering 64-bit file lengths, but I wonder if this is going to be a widely-used format or not (personally I've never heard of it :)
Also - I have three dolist items for soundfiler/read/writesf~ :
fix thread-unsafe way readsf~ searches along the file path (need to make a local copy of the path so that the sub-thread isn't asking the canvas to do the search via open_via_path)
allow reading and writing ASCII text files (way way overdue!)
fix writesf~ to make running updates to the chunk size as the file grows, so that if the file never gets 'closed' it still gets a reasonable size
None of this is the least bit fun or interesting I'm afraid...
cheers Miller
On Thu, Apr 18, 2019 at 10:36:21PM -0300, Alexandre Torres Porres wrote:
Em qui, 18 de abr de 2019 ??s 14:22, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
???Why not???? would come from other maintainers who do not necessarily want to be stuck with yet more code. I???m pretty sure I can structure this in a way to fit in with the object already works, but I???d rather not try if there is no interest in recovering the code.
Sure, I see. I hope then you can get it working in a way that doesn't raise any concern to Miller. I'll stress again that it can be useful at least for the loop and sound effects library from *Soundtrack Pro* and *Logic Studio* .
it may not be too difficult to dump the extra info but that???s a separate issue.
yeah, I had opened this one <https://github.com/pure-data/pure-data/issues/586 https://github.com/pure-data/pure-data/issues/586>
cheers
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I'd also be up for an equivalent format, maybe RF64 which looks like a 64-bit WAV: https://en.wikipedia.org/wiki/RF64 https://en.wikipedia.org/wiki/RF64 I'm not sure yet what could be consisted the "standard" for this. Maybe we should look at what files are used by Max, Ableton, etc.
Our main requirements are capacity for long length / large file sizes and multi-channel. The new version of our project could then convert CAF files to something else, as long as it's equivalent. We have numerous pieces which use 24-bit 8 channel files over 20 minutes in length, so we definitely need the large file support.
On Apr 19, 2019, at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
This is something that I could potential do at work and tackling that list could probably be part of it. I was thinking of making a generic interface so that file types could be split into separate .c files like the audio & midi backends. This would make adding a new format much easier and improve maintenance as well.
This is something that probably would happen more in late summer-fall time, although I could imagine doing smaller aspects of it beforehand for 0.50. I could justify using this time for the overall project, to some degree. :)
On Apr 19, 2019, at 6:35 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I'm of two minds about this - I think it would be excellent to start offering 64-bit file lengths, but I wonder if this is going to be a widely-used format or not (personally I've never heard of it :)
Also - I have three dolist items for soundfiler/read/writesf~ :
fix thread-unsafe way readsf~ searches along the file path (need to make a local copy of the path so that the sub-thread isn't asking the canvas to do the search via open_via_path)
allow reading and writing ASCII text files (way way overdue!)
fix writesf~ to make running updates to the chunk size as the file grows, so that if the file never gets 'closed' it still gets a reasonable size
None of this is the least bit fun or interesting I'm afraid...
cheers Miller
On Thu, Apr 18, 2019 at 10:36:21PM -0300, Alexandre Torres Porres wrote:
Em qui, 18 de abr de 2019 ??s 14:22, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
???Why not???? would come from other maintainers who do not necessarily want to be stuck with yet more code. I???m pretty sure I can structure this in a way to fit in with the object already works, but I???d rather not try if there is no interest in recovering the code.
Sure, I see. I hope then you can get it working in a way that doesn't raise any concern to Miller. I'll stress again that it can be useful at least for the loop and sound effects library from *Soundtrack Pro* and *Logic Studio* .
it may not be too difficult to dump the extra info but that???s a separate issue.
yeah, I had opened this one <https://github.com/pure-data/pure-data/issues/586 https://github.com/pure-data/pure-data/issues/586>
cheers
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
In the meantime, you might be able to read CAF files by simply ignoring the header (asuming the data is 16 or 24 bit fixed-point or 32 bit float).
cheers M
On Sat, Apr 20, 2019 at 11:08:39PM +0200, Dan Wilcox wrote:
I'd also be up for an equivalent format, maybe RF64 which looks like a 64-bit WAV: https://en.wikipedia.org/wiki/RF64 https://en.wikipedia.org/wiki/RF64 I'm not sure yet what could be consisted the "standard" for this. Maybe we should look at what files are used by Max, Ableton, etc.
Our main requirements are capacity for long length / large file sizes and multi-channel. The new version of our project could then convert CAF files to something else, as long as it's equivalent. We have numerous pieces which use 24-bit 8 channel files over 20 minutes in length, so we definitely need the large file support.
On Apr 19, 2019, at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
This is something that I could potential do at work and tackling that list could probably be part of it. I was thinking of making a generic interface so that file types could be split into separate .c files like the audio & midi backends. This would make adding a new format much easier and improve maintenance as well.
This is something that probably would happen more in late summer-fall time, although I could imagine doing smaller aspects of it beforehand for 0.50. I could justify using this time for the overall project, to some degree. :)
On Apr 19, 2019, at 6:35 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I'm of two minds about this - I think it would be excellent to start offering 64-bit file lengths, but I wonder if this is going to be a widely-used format or not (personally I've never heard of it :)
Also - I have three dolist items for soundfiler/read/writesf~ :
fix thread-unsafe way readsf~ searches along the file path (need to make a local copy of the path so that the sub-thread isn't asking the canvas to do the search via open_via_path)
allow reading and writing ASCII text files (way way overdue!)
fix writesf~ to make running updates to the chunk size as the file grows, so that if the file never gets 'closed' it still gets a reasonable size
None of this is the least bit fun or interesting I'm afraid...
cheers Miller
On Thu, Apr 18, 2019 at 10:36:21PM -0300, Alexandre Torres Porres wrote:
Em qui, 18 de abr de 2019 ??s 14:22, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
???Why not???? would come from other maintainers who do not necessarily want to be stuck with yet more code. I???m pretty sure I can structure this in a way to fit in with the object already works, but I???d rather not try if there is no interest in recovering the code.
Sure, I see. I hope then you can get it working in a way that doesn't raise any concern to Miller. I'll stress again that it can be useful at least for the loop and sound effects library from *Soundtrack Pro* and *Logic Studio* .
it may not be too difficult to dump the extra info but that???s a separate issue.
yeah, I had opened this one <https://github.com/pure-data/pure-data/issues/586 https://github.com/pure-data/pure-data/issues/586>
cheers
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I'll give that a try, although it won't work for us with anything > 4GB as we use the offset for setting playback location.
On Apr 21, 2019, at 12:12 AM, Miller Puckette msp@ucsd.edu wrote:
In the meantime, you might be able to read CAF files by simply ignoring the header (asuming the data is 16 or 24 bit fixed-point or 32 bit float).
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Which actually makes me think... even if Pd supported a file type that used 64-bit sample offset, it wouldn't be able to address that whole range with just a float.
On Apr 22, 2019, at 1:47 PM, Dan Wilcox danomatika@gmail.com wrote:
I'll give that a try, although it won't work for us with anything > 4GB as we use the offset for setting playback location.
On Apr 21, 2019, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
In the meantime, you might be able to read CAF files by simply ignoring the header (asuming the data is 16 or 24 bit fixed-point or 32 bit float).
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 4/20/19 11:08 PM, Dan Wilcox wrote:
I'd also be up for an equivalent format, maybe RF64 which looks like a 64-bit WAV: https://en.wikipedia.org/wiki/RF64 https://en.wikipedia.org/wiki/RF64 I'm not sure yet what could be consisted the "standard" for this. Maybe we should look at what files are used by Max, Ableton, etc.
when we (the IEM) designed the AmbiX fileformat (for higher order ambisonics recordings) a couple of years ago, we looked for an open "standard" fileformat that allowed us to have many channels which easily exceed any 4GB limit (not to talk about 2GB limits as with most WAV implementations).
in the end we opted for CAF, as it has (iirc) a much cleaner design all attempts to engage WAV and 64bit. e.g. RF64 seems (i forgot everything and just looked it up on the wikipedia article dan linked to) to have a limitation of 18 (surround) channels. wtf?
so yes. CAF would be a nice addition to support, although it can be a very complex format. just supporting a basic set (a single PCM data chunk) would be simple enough i guess.
I don't see any inherent problem with the 64bit format in single-precision Pd (even with miller's suggestion to just skip the header, you would only get into trouble if the header (and "early chunks") would be longer than 2^24 bytes; whenever it comes to lengths, you are mostly dealing with *frames* rather than *bytes*, so the numbers should be scaled down reasonably anyhow; and of course, we want a double-precision rather sooner than later anyhow)
gfmadsr IOhannes
On 23/4/19 3:58 am, IOhannes m zmölnig wrote:
so yes. CAF would be a nice addition to support, although it can be a very complex format.
https://github.com/erikd/libsndfile/blob/master/src/caf.c
Em sex, 19 de abr de 2019 às 13:35, Miller Puckette msp@ucsd.edu escreveu:
I'm of two minds about this - I think it would be excellent to start offering 64-bit file lengths, but I wonder if this is going to be a widely-used format or not (personally I've never heard of it :)
Also - I have three dolist items for soundfiler/read/writesf~ :
fix thread-unsafe way readsf~ searches along the file path (need to make a local copy of the path so that the sub-thread isn't asking the canvas to do the search via open_via_path)
Just to be sure, that would fix this issue, which now just can't be done unless we change things under the hood, huh? https://github.com/pure-data/pure-data/issues/234#issuecomment-337183458
I guess that makes a case for reopening that issue, it was marked as "wontfix".
cheers
-
Alexandre Torres Porres -
Chris McCormick -
Dan Wilcox -
IOhannes m zmölnig -
Miller Puckette