Does the Audio File In CHOP read multichannel WAV files over 4GB (RF64/BW64, or Wave64 .w64), streaming the full duration without truncating at the 4GB mark?
I need to play back a single file with 65-channels (48kHz, 16-bit, ~15 min, ~5.6GB) Locked to Timeline. The docs say it streams from disk and keeps only a few seconds in memory, but say nothing about RF64/ds64 support.
- is there a channel-count ceiling for the Audio File In CHOP
- is RF64 or Wave64 more reliable in TD?
Computer I’m using to build the show: TD 2025.32280, M1 Macbook Pro, 16GB RAM, macOS 14.7.5
Computer we will run the installation on: M series mac mini (haven’t decided yet which one) with 16 or 32 RAM
Thanks!
It looks like you can just rename your .w64 files to .wav and we’ll play them fine. I’ll add .w64 to the list of extensions we support for future builds though.
1 Like
Very cool! Thanks so much for this!
One more question for ya: is there a maximum channel count the Audio File In CHOP will read and stream? My show file is now 67 channels. It will be a single Wave64 file, 48kHz, 16-bit, about 15 minutes long, played back Locked to Timeline. I want to confirm the CHOP will carry all of them before I commit the whole show to a single file. For my workflow, keeping it as one single file is preferred instead of lots of wavs
You’d have to test and see, but the 65 you request should work. In theory its 512, but its possible there are limits in other places.
1 Like
Following up on this with a full test I ran since your last reply, since it turned up something concrete worth flagging.
I built out the 65-channel show file (48kHz, 16-bit) and it wouldn’t load in the Audio File In CHOP at all, “File format not recognized.” To isolate why, I bisected channel count directly using short (5-minute) test files, all built identically with sox, same flags, same trim, only channel count changed. These were written as plain RIFF WAV:
I then re-tested at 65ch specifically as a genuine Wave64 file (renamed to .wav afterward, same as my original full-length show file), to rule out container format as a factor. Same failure, identical error. So the ceiling holds across both plain WAV and Wave64 containers, across file sizes both under and over 4GB, and it’s specifically triggered by crossing from 64 to 65 channels.
Worth noting: ffmpeg’s amerge filter has this exact same 64-channel ceiling built in (its own error message says “Too many channels (max 64)”), so this might be a shared convention somewhere in how multichannel PCM gets indexed, rather than something specific to your decoder.
I’m working around it for now by splitting my show across two Audio File In CHOPs locked to the same timeline, but I wanted to flag this clearly in case it’s something that could get lifted in a future build, since my current plan involves 67 channels total (65 laser + 2 audio) and a single-file workflow would be a lot cleaner for a permanent unattended install like the one I’m building. Happy to share test files or more detail if that’s useful for tracking it down.
Thanks for sample. It does seem like a 64 channel limit is hit due to an sample format conversion library limitation. I think I can fix this in our next 2026 release, but the change is too large to fix for 2025. For now you’ll need to split your files. Sorry
1 Like
That’s ok, I will split them!
That’s amazing that you think it could be fixed in the future though, very exciting!