atldotnet and one managed API for tags across every audio format

A tag library, and the boundary it deliberately keeps

The Audio Tools Library for .NET is aimed at giving .NET developers a managed, portable and easy-to-use library to read and write metadata from digital audio files and playlists with one single unified API, whatever the underlying format.

What it is not, according to the README, is stated just as plainly. It is not a standalone application, since it is a library aimed at being used by developers to build software. And it is not an audio music player: it gives access to various properties and metadata, but it does not process audio data into an audible signal.

That second exclusion is the one that matters when you are choosing. ATL lives entirely in the metadata layer. It knows where the tag blocks sit inside a container, how they are structured, and how to rewrite them, but it does not decode PCM, it does not give you a waveform, and it will not tell you what a track sounds like. If your application needs to read the samples, you need a decoder alongside it and ATL handles only half of that job.

The naming also has a history worth noting. The README explains that ATL has been open source since its creation, that the original ATL 2.3 source written in Pascal is still on Sourceforge, that the MAC team helped many developers by publishing their work, and that the current maintainer is extending and improving their initial contribution.

The audience is therefore a developer building a tagging tool, a catalogue manager, a converter or a media library service, who wants the same code path regardless of what the file on disk happens to be.

The licence is MIT, the package is published on NuGet as z440.atl.core, and the current stable release is 7.18.

How the unified API works

The core abstraction is a Track object, and the README's example shows how little you need to know about the format to use it.

using ATL.AudioData;

// Initialize with a file path
Track theTrack = new Track(audioFilePath);

// Works the same way on any supported format (MP3, FLAC, WMA, SPC...)
System.Console.WriteLine("Title : " + theTrack.Title);
System.Console.WriteLine("Duration (ms) : " + theTrack.DurationMs);

theTrack.Save();

The Track can be constructed from a file path or, alternatively, from a Stream, which is what lets you work on a file you have not written to disk, or on a stream inside a container.

Two features of the object model are worth calling out. The first is that the format is detected rather than declared. The README lists auto-detection of the format of the audio data you are using as a reason to prefer ATL over TagLib, specifically noting that it works even if the file extension has the wrong label, or if you are feeding it raw data without context. The second is that the same property names work across every container, so Title and DurationMs mean the same thing whether the file underneath is an MP3 or a DSF.

The API also reaches past the common fields. The README's example writes a custom field through AdditionalFields, which is a dictionary on the Track for tags that have no standard slot, and it shows a Composer assignment that carries characters outside the Latin range, with the comment noting support for exotic charsets. The metadata notes for the format table state the same principle at scale: all metadata is read according to Unicode/UTF-8 encoding when applicable, which means foreign characters will be recognized and displayed properly.

There is also an async path. The README lists support for async calls on writing operations, with progress feedback, which matters when you are tagging thousands of files rather than one.

The format table, and where read and write differ

The centre of the documentation is a table of audio formats against tagging standards, with R and W marking read and write support, and empty cells meaning not applicable for that format.

The mainstream formats are covered for both directions. MPEG Audio Layer with the .MP1, .MP2 and .MP3 extensions shows R/W across ID3v1.0-1.1, ID3v2.2-2.4 and APEtag. FLAC has R/W for ID3v2 and R/W for format-specific tagging. OGG with .OGG, .OGA, .OPUS and .SPX extensions, covering Vorbis, Opus, embedded FLAC and Speex, has R/W for format-specific tagging. WMA and ASF, MKA and WEBM, WAV, BWF, APE, MPC, MP+, OFR, OFS, TTA, WV, AIF, ALAC, M4A, M4B, AAC, AAX, AA, DSD, DSF and DFF all appear with support in at least one direction.

The differences are where a reader gets caught out, so the footnotes matter as much as the table. The first is that ATL reads ID3v2.2, ID3v2.3 and ID3v2.4 tags but writes only ID3v2.3 and ID3v2.4 tags, so an old ID3v2.2 tag is readable but will be rewritten in a newer form. The second is that in the tracker formats, Extended Module, Impulse Tracker, ScreamTracker and Noisetracker, all sample names appear on the track's Comment field and only the track title is editable, since those formats have no field for the rest.

The third footnote is the one that separates ATL from most tag libraries, and it is a whole category rather than a cell. ATL supports the video game audio formats, which the README lists as SPC, PSF and VGM along with GYM, and the table confirms it with rows for SPC700 Super Nintendo sound files, Portable Sound Format with its many variants including MINIPSF, SSF, DSF, GSF and QSF, Genesis YM2612, VGM and VGZ for SEGA systems, and Extended Module and Impulse Tracker.

The reason that matters is that a large amount of music in the world exists only in those formats, and they have no standard tagging system at all. ATL writes a consistent set of metadata into them, which is the whole point for someone with a retro game music collection.

Chapters, lyrics and the RIFF chunk zoo

Beyond ordinary tags, ATL supports a set of metadata types that other libraries tend to leave out, and it supports them natively rather than through a plugin.

Chapters are one of these, with the README linking a dedicated chapter metadata page. Chapters matter for long-form content, an audiobook or a DJ mix, where a single set of ID3 frames is a poor fit for a structure with dozens of named sections.

Lyrics are the other, with their own linked page. Synchronised lyrics are a specific format with timing information, and treating them as an ordinary text frame loses the timing.

Then there is the RIFF and WAV chunk support, which is the densest part of the list: BEXT, the broadcast extension chunk carrying originator and coding history information; LIST, described as general metadata, labels and notes; CUE, which gives cue points; SMPL, which carries sample loops; DISP for displayable objects; and XMP, CART and iXML metadata chunks.

Those chunk names are obscure enough that a reader may wonder why they matter. The reason is provenance. A WAV file that has been through a broadcast chain, or an audio library that carries loop and cue point data, has that data in these chunks. A tag library that only reads ID3 and RIFF INFO will silently drop it on the next save, which for a library that cares about preserving the file is a data-loss bug rather than a missing feature.

Playlists and CUE sheets are supported as well, and the README lists them as a single bullet among the reasons to prefer ATL. A CUE sheet describes the tracks within a single album file, which is a different problem from reading the tags of one file, and the fact that ATL handles it means a tool can map a cue sheet onto individual tracks without a second dependency.

On top of that, the README mentions embedded pictures such as cover art, chapters and lyrics as things the code snippets in the wiki documentation cover.

Why the author picked ATL over TagLib

The README has a section asking why one would use ATL while TagLib exists, and the answers are specific enough to be worth repeating because each one is a different kind of difference.

The first is implementation. ATL has a full C# implementation and uses no dependency, which the README says makes portability trivial if your application is already based on .NET or Mono frameworks. TagLib is a C++ library with bindings, so the comparison is not really ATL against TagLib the library but ATL against TagLib plus a binding layer plus a C++ toolchain in the build.

The second is detection. ATL auto-detects the format of the audio data you are using, even if the file extension has the wrong label or if you are feeding it raw data without context.

The third is observability. ATL features a flexible logging system which allows you to catch and record audio file reading and writing incidents into your application. That is a real operational difference for a batch job, where you want to know which files were rewritten and which failed, and where the library's own diagnostics flow into your logs.

The fourth is format coverage, with ATL supporting more audio formats than TagLib, including video game audio formats. The fifth and sixth are native chapters and native lyrics support, and the seventh is the playlist and cue sheet handling.

The eighth is asynchronous writing. Put together, the list describes a library built for a .NET developer who wants the whole job in managed code: detection, logging, async writes and a wide format matrix, none of which requires shipping a native binary alongside the application.

Platforms, tooling and what the repository holds

The library targets .NET Standard 2.1+ and .NET 6+, and the unit tests run on .NET 6+. The README states that the library and its tests have been maintained on Visual Studio Express and Community, currently on Community 2022, so the development environment is a mainstream Microsoft one rather than something exotic.

The repository layout matches a long-lived library. There is ATL/ for the library itself, ATL.unit-test/ for the test suite, ATL.benchmark/ for the performance harness, and ATL.UI-test/ for the user interface tests. The ATL.sln solution ties them together. The coverlet.runsettings and runsettings.runsettings files configure the two test frameworks in play, and wiki-images/ holds the images used in the wiki documentation.

The tooling badges in the README tell you what the maintainer relies on: ReSharper for the code, BenchmarkDotNet for the benchmarks and CodeTrack for source control analysis. The CI setup shows a .NET workflow badge, a SonarCloud coverage badge for new code, and a SonarCloud quality gate status badge, which together mean coverage and static analysis are tracked continuously rather than occasionally. The NuGet publish workflow has its own badge, so a release goes out through the pipeline.

Release cadence is visible too. The three most recent versions are 7.16 from 2026-08-05, 7.17 from 2026-09-16 and 7.18 from 2026-09-28, and the repository's last push was on 2026-09-28. For a library that ships into applications through NuGet, that is a meaningful signal, because a version bump reaches your build on your next restore rather than through a manual update.

The documentation lives in the GitHub wiki rather than in the repository, with a code snippets section that the README points to several times as the place to find working examples for embedded pictures, chapters, lyrics and playlists.

Editorial conclusion

atldotnet is a good fit for a .NET application that has to read or write tags across a mixed library, because one API covers the mainstream formats, the game audio formats most tag libraries skip, and the exotic metadata chunks, all in managed code with no native library to ship. It is a poor fit if you need to decode or process the audio itself, since the README is explicit that ATL does not turn audio data into an audible signal, and a poor fit if you need a supported .NET version older than .NET Standard 2.1 or .NET 6. Before adopting, check the format table for the specific container you care about, since read and write support differ per format and per tagging standard, and note that ATL reads ID3v2.2 through 2.4 but writes only 2.3 and 2.4.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Zeugma440/atldotnet on GitHub