Feature Enhancement: mka support

[BrianAker]

Matroska Audio (MKA) is the container format specified for .mka files and is part of the same family as .mkv files. The FAQ on Matroska provides a good starting point for learning more: https://www.matroska.org/faq.html.

Atldotnet supports MKA: https://github.com/Zeugma440/atldotnet/tree/main

Why support MKA when so few players currently support it?

Many audiobook recordings have been archived by chapter in MP3 format, but managing these files can come with numerous challenges (which I won’t elaborate on here). Re-encoding them to M4A/M4B formats involves a quality penalty due to conversion to AAC. While encoding to ALAC results in playable files, the file size becomes quite large. Although it’s possible to use FFmpeg to create M4B files with embedded MP3s, most players struggle to handle files stored this way, often becoming confused.

With MKA files, you can store the original MP3 files, complete with tags, cover art, subtitles, and more—effectively preserving an entire series in one file.

Another advantage of MKA files is the ability to update tags without modifying the audio data itself; however, it’s unclear to me if the atldotnet library currently supports this feature.

MKA supports nested tagging; I have no idea how tone would handle displaying this sort of data.

For archival purposes, where re-encoding penalties are a concern, MKA appears to be a promising solution.

I don't know if this is within scope, but I didn't find a record of anyone having asked about it.

[sandreas]

Are you sure tone doesn't already support mka?

Maybe just try it I don't see a reason it shouldn't work

[Zeugma440]

Atldotnet dev here 😄

Another advantage of MKA files is the ability to update tags without modifying the audio data itself; however, it’s unclear to me if the atldotnet library currently supports this feature.

I'm not sure what you mean there. By nature, metadata is separated from audio data. As long as you're not venturing into steganography, updating tags shouldn't have any impact on audio data, whatever format you're using.

MKA supports nested tagging; I have no idea how tone would handle displaying this sort of data.

Atldotnet does not support nested MKA tagging for now. As far as I'm concerned, it looks like something that is theoretically nice, but with few practical uses. I'd love to be wrong about that and to hear about field use cases btw 😉

[BrianAker]

I think the next step is that I need to provide you with some examples. In some circumstances I am finding that, for instance, the TITLE tag is being found but no other tag is being displayed. In other cases tone is not able to identify that the file had audio data in it at all.

If it would be useful I can generate some files, with a randomly generated audio source, and provide them along with the methods used for generating them ( with chapters ). This is what I did with libid3, which I found to be useful.

[BrianAker]

@Zeugma440

In regards to editing mka files in place, from man page for mkvpropedit, "This program analyses an existing Matroska(tm) file and modifies some of its properties. Then it writes those modifications to the existing file."

I believe this one of the motivations for the Matroska design, though I may be misremembering. Rewriting the entire file introduces the opportunity for corruption; it also hits IO locally as well creating a worse case for replicated storage ( block storage, etc... ).

More information on how this works can be found here:
https://www.matroska.org/technical/ordering.html

[Zeugma440]

@BrianAker that's pure marketing imho. In terms of file I/O, as long as some of your metadata is located at the beginning of the file, you have to rewrite the file all the way to its end as soon as you add or remove one extra byte of metadata. Plus MKA sitting on top of EBML literally begs you to rewrite Element headers -and even change their size according to their value.

APEtag is the only standard metadata format I know that gets written at the end of the audio file and effectively limits I/O operations upon editing. But it does not play nice with streaming, as metadata is lost at the very end of your file :/

PS : ID3v1 does that too but it's so basic that it isn't fit for modern use