Matroska audio container support

[TheMinefighter]

The problem

I would love to see support (at least read) for matroska audio containers (*.mka), which are quite popular

Details

MKA files are currently not working with ATL. For technical details about the format there is the official specification page.

[Zeugma440]

Thanks for the suggestion and the specs page. I'm gonna look into it.

However I'm quite surprised to hear they are quite popular, as I'm an audio fan myself, and have not come across these yet.

Could you tell me -for my own curiosity- in which circles/domains they are popular ? And most importantly, do you know where I can find sample files ?

[TheMinefighter]

Matroska is popular in the open source world (at least here in Germany), due to the fact that all of it is open source, that they are widely supported (even natively on Windows) and it has an extensive feature set that other formats (e.g. .opus) don't have. Sample files of course can be generated with ffmpeg, use -codec:a [Codec] for different codecs. If you need any help with sample files feel free to contact me.

[Zeugma440]

Alright, thanks for answering. I'll see what I can do in the following weeks. I'm in the process of releasing another project, so it might not be immediate 😉

In any case, I'll let you know by posting in this Github issue.

[Zeugma440]

Test files
https://github.com/Matroska-Org/matroska-test-files/tree/master/test_files
https://kodi.wiki/view/Samples
https://mkvtoolnix.download/samples/

[Zeugma440]

In my very own opinion, the MKV container illustrates the definition of "overengineered" : it covers all expected features of a multimedia container, allows flexibility, occupies just the required disk space without any useless byte.... but boy, the more I'm reading, the more I realize I need to read even more stuff.

The underlying EBML binary format -their very own creation- is also quite a piece of art (think "Escher" - extremely well structured but very intricate, to the point of convolution) compared to what I've seen on all the other formats the library supports.

In conclusion, implementing support for MKV inside the ATL library without relying on MKV tools will be a long, hard path to follow, especially if we aim at reading and writing data.

I'm leaving this issue open but I don't guarantee it will be implemented soon.

[loudenvier]

I'm in the process of writing a file "auto-organizer" application (for my own sanity as I can't organize my library manually anymore, but will be releasing it as open source) and I was looking at Metadata Extractor to extract metadata for common files, then realized they didn't support the matroska container. So I planned to add support to mkv back into Metadata Extractor by using either NEbml or Matroska (which uses NEbml)... Then I found your library which already does something I'll have to do myself: normalize common tags (like title, author, etc.). And stumbled on this request and fully agree with your comment regarding the container format :-)

That said, it can be somewhat easy to add support for matroska (and webml) using those two libraries. If you don't want to add new dependencies, you can extract the bare minimum code to read only the "Tags" EBML Segment. Or it could be added as an "extra" project which depends on NEbl or Matroska but don't pollute the core project.

Anyway, now that I've found your library I will certainly be using it (with or without matroska support :-) Thanks for the great work.

[Zeugma440]

Thanks for the kind words @loudenvier

I should at least give it a try to see how large is the bare minimum code to do what is needed in ATL

[loudenvier]

I'll give it a shot! I've found another dotnet library which is simpler to use and looks fast. I could just add it directly from the source to prevent any needless dependency. Will post back as a PR so you can see if it's good enough, change it if its not or reject it is bad :-)