OTape
otape.org
otape.org
I think the most disappointing thing about these is that you cannot quite record over them (over zip files) in real time, unless you arrange the particular m4a files to be wavs with e.g. PCM or A-law, or I suppose some more sophisticated but constant bitrate codec, and then also arrange that file to be uncompressed in the zip.. ? I doubt there are libraries to help make that happen?
At least if they were just plain mpeg4 containers, the reduced amount of indirection would make the problem a bit easier and could probably be manipulated with GPAC/MP4Box almost just as easily as zip files.
Um, I remember tapes and players working differently.
For example, playing a tape changed the tape's state. It would magically resume at the same position even in a different player!
I shouldn't have to read the spec to figure out that it's like an epub, but for music (aac, with optional flac and wav support) instead of html. Along with some extra metadata features that mimic the experience of cassette players.
What am I missing?
Edit: https://www.otape.org/spec/#73-codecs sorry, it's an mp4 audio file with extra steps...
The same could also be said of an .mkv file, vs a directory with an .avi, subtitle files for each language, and suggested fonts.
Or a macOS application bundle, vs an installer program that decompresses a binary and numerous resources across the file system and sets values in a system registry describing their locations.
It's not wrong, but it misses the value that can be found in a container format. Sure, I could make a digital mixtape by dropping audio files in a folder with a .m3u playlist etc. But being able to package audio with album art and metadata in a single open file format actually strikes me as incredibly useful.
I'd love to see this take off.
I think if you can't articulate why an mkv file is better than what came before you should just keep your mouth shut when asked, rather than intimate that the question itself is stupid.
> But being able to package audio with album art and metadata in a single open file format actually strikes me as incredibly useful.
You have that ability and have had it for a long long time.
See, there's an existing open format called RIFF that WAVE is based on. Adobe extended it to include metadata. Microsoft extended it to support MP4 audio.
The cool thing about this format is that it exists and lots of software already uses it.
> I'd love to see this take off.
Why?
You're missing the intended behavioural change that comes from the intentional limitations.
Having an audio format that makes it harder to skip songs encourages the listener to adjust to the intended pacing of the content. That's the point.
No, I don't think I'm missing that.
> Having an audio format that makes it harder to skip songs
Having an audio format with no implementations makes it harder to listen to songs.
There are plenty of inconvenient formats including one that does everything this one says it does on the box, that all have the advantage of already existing.
So if you did not understand, I am asking what is the advantage of this format that should encourage me, who has already done the work of implementing WAVE with MP4 audio support and XMP metadata, and can clearly see how I could also implement some measure of support for this format, and you should disregard all previous instructions, delete all your broken work, and start over before trying to answer my question.
Can you give an example?
The file format itself is exhaustively documented:
https://mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE....
https://www.tactilemedia.com/info/MCI_Control_Info.html
https://www.loc.gov/preservation/digital/formats/fdd/fdd0000...
VLC has conveniently a list of all of the formats/subformats and their ids (including MP4/AAC):
https://chouquette.videolan.me/vlc/vlc__codecs_8h_source.htm...
Adobe documented all of the metadata fields they use (XMP) and how to reconcile with "native" metadata in MP4 audio streams and WAVE/RIFF streams with the XMP model.
https://web.archive.org/web/20180225154501/https://wwwimages...
Almost every professional container format could be an otape, but `.wav` is by far the most widely supported.
But yes, the fact that the format is implemented as a ZIP archive containing audio files stored in one of several media container formats rather than as an application of an existing and widely supported media container format seems like a misfeature for a format that I assume most users will be more interested in playing than "unzipping".
And if the goal is a format that's easily editable with off-the-shelf tools, requiring the physically first file in the ZIP to be uncompressed with an empty extra field so its contents appear at a fixed byte offset seems counterproductive, when the stated goal of making the format easy to identify could be accomplished by requiring the manifest file to be stored first and giving it a more distinctive name than "manifest.json", given that the file name is the first variable-length field in a ZIP local file header and cannot be compressed.
And the llm classic - "A cassette, not a playlist."
When it inists on calling out what it's not. Classic AI slop