Tag Editor: a Qt and CLI tag editor for MP4, FLAC, Vorbis, Opus and Matroska

The problem: editing metadata without damaging the file

A tag editor looks like a trivial program until you remember that a media file is a structured container, and that a tag is a small structure embedded in it. Write the tag in the wrong place and the file no longer plays. Change the size of a structure and the offsets elsewhere in the file have to be recomputed. Add a field that the format does not expect and a strict player may reject the whole file.

Tag Editor is a tag editor with a Qt GUI and a command-line interface, supporting MP4, ID3, Vorbis, Opus, FLAC and Matroska, and the design decision that shapes everything else is the handling of the rest of the file. The documentation is explicit that unsupported file contents, such as unsupported tag formats, are generally preserved as is. That is the behaviour you want from a metadata tool, because the thing you did not ask it to change must survive your having used it.

The audience is two overlapping groups. The first is a person with a music or video library whose metadata is wrong and who wants a graphical way to fix it, including cover art, without a command line. The second is a person who has to script the same change across thousands of files, and who needs the same format coverage from a command line as from the GUI.

The project is written in C++ with a Qt interface, is licensed under GPL-2.0 with a LICENSE.LESSER file also present, and the last push was on 2026-10-18. The releases are v3.9.11 from 2026-07-09, v3.9.10 from 2026-05-14 and v3.9.9 from 2025-12-02, so the 3.9 line is where the work is.

The format coverage, and the one format that is deliberately dropped

The supported list is broader than most tag editors, and it is worth reading closely because the differences between formats drive most of the configuration options.

For MP4 and M4A the tool handles iTunes-style tags, and MP4-DASH is supported as well. For MP3 there is ID3v1 and ID3v2, with conversion between ID3v1 and the different versions of ID3v2 possible, and the documentation notes that these tags are mainly for MP3 files but can be added to any kind of file. For Ogg streams there are Vorbis, Opus and FLAC comments, with cover art through METADATA_BLOCK_PICTURE, and the same two mechanisms are supported in raw FLAC streams. Matroska and WebM tags and attachments are supported too.

One format is explicitly out: APE tags are not supported. The reasoning given is that APE tags at the beginning of a file are strongly unrecommended and are thus discarded when applying changes, while APE tags at the end of the file are preserved as is. So it is not that the tool cannot read them, it is that it will drop a leading one, because a leading APE tag is itself a bad idea.

The tool also displays technical information, not just tags: the ID, format, language, bitrate, duration, size, timestamps, sampling frequency and FPS of the tracks. And it can inspect and validate the element structure of MP4 and Matroska files, which is a genuinely useful diagnostic when a file will not play and you do not know why.

The repository layout matches the two front ends: a gui/ directory, a cli/ directory, an application/ directory, a renamingutility/ directory for batch renaming, a dbquery/ directory, resources/, tests/, testfiles/ and translations/.

Rewriting is the default, and the temporary file is your backup

This is the part of the documentation every user should read before pointing the tool at a library, and the design is unusual enough to deserve explanation.

Sometimes the tag editor has to rewrite the entire file to apply changes, and that leads to the creation of a temporary file. With the GUI's default settings this is even enforced, to be conservative, because the temporary files also serve as a backup in case something goes wrong, such as a crash while saving, or a bug that breaks particularly structured files.

The consequence for the command line is a counter-intuitive recommendation. Because the temporary file is your backup, the documentation recommends that CLI users also use force rewriting. The default CLI behaviour, which tries to avoid a rewrite, is therefore the less safe option, and the safer one is the one that does more work.

That is a defensible engineering position, and it comes with a price. A rewrite means the file is fully written again, which for a large Matroska file is a real cost, and the documentation later spends a good deal of space on how to avoid rewrites anyway. The temporary file location can be configured in the GUI settings or with the CLI option --temp-dir, and the documentation advises putting the temporary directory on the same filesystem as the files being edited, for efficiency. There is also an honest admission that a feature to delete temporary files automatically has not yet been implemented, so the temporary directory is yours to clean.

For a scripted pipeline, that combination is the thing to plan around: force the rewrite, keep the temporary directory on the same filesystem, and add your own cleanup step.

Tag position, index position and the faststart question

The file layout options are the most technical part of the tool and the part that most affects what happens to your files under the hood.

The first control is tag position. The editor lets you choose whether tags are placed at the beginning or at the end of an MP4 or Matroska file, and putting them at the end can avoid having to rewrite the entire file to apply changes. In the command line this is the --tag-pos option, and to enforce a specific tag position even when that requires a rewrite, you combine it with the --force option. There are format limits: ID3v2 tags and Vorbis and Opus comments can only be placed at the beginning, ID3v1 tags can only be placed at the end, and so the setting has no effect for those formats.

The second control is index position, which is where the cues or index live. It is currently only supported for Matroska files, because in MP4 the tags and the index are tied together, so the index position always follows the tag position. Putting the index at the beginning is sometimes called faststart, and forcing it from the command line takes two options:

tageditor set --index-pos front --force

The third control is padding, which reserves space in the file so that more tag information can be added later without rewriting the file or appending the tag. The configuration covers minimum and maximum padding, where the file is rewritten if the padding would fall below or exceed the limits, and a preferred padding, which is used if a rewrite happens anyway.

The relevant command line options are --min-padding, --max-padding, --preferred-padding and --force-rewrite. One limitation is stated: taking advantage of padding is not currently supported for Ogg streams, though it is supported for raw FLAC streams.

Avoiding rewrites, and what it costs you

The documentation does not just describe the options, it tells you how to turn off the safety net, and it says so in as many words: avoiding a rewrite is not a good idea, as the temporary file that is created when rewriting the entire file also serves as a backup.

If you still want to avoid rewriting the file as much as possible, the GUI File layout settings are: the Force rewrite option unchecked, the Use preferred position options unchecked, minimum padding set to 0, and maximum padding set to 429496729, described as simply a very high number. From the command line, you need to add --max-padding 429496729 to the arguments and avoid the other options mentioned earlier.

Performance has its own advice, and the two are in tension. Editing large files, especially Matroska files, can take some time. To improve performance, put the index at the end of the file with the CLI option --index-pos back, because then the size of the index never has to be recalculated. The documentation also recommends forcing a rewrite, since the tag editor can then skip the computations that would decide whether a rewrite is necessary, and those computations are what take a notable amount of time for large Matroska files. If you do want to avoid a rewrite, put the tag at the end with --tag-pos back so that the tool does not even try to place tags at the front.

The summary is a deliberate inversion of the usual advice. If you rewrite, you are safe and slow. If you avoid rewriting, you are fast and unprotected. A reader who understands that trade is ready to use the tool; a reader who reads only the option names is not.

The remaining piece is the Matroska specifics, which the documentation flags because the container deviates from common conventions and not all command line examples apply. A single Matroska file can contain multiple tags, each with a target determining what its fields apply to, such as an individual song or the entire album, so you have to be mindful of which tag or target you are adding fields to. Matroska also does not use one combined field for the track or disk number and total as other formats do, but the separate fields part and totalparts, which again have to be added to a tag of the desired target, for example 50 and ALBUM for the track number and total.

Licence, maintenance and where this is the wrong tool

The project is licensed under GPL-2.0, with a LICENSE file at the root of the repository and a LICENSE.LESSER file beside it, and there is a separate document covering the Windows distribution licences. For a desktop utility that you run on your own files, the practical consequence is that you can read the code, and that if you redistribute the tool you have to carry the terms with it.

The project is not archived and the last push was on 2026-10-18, with the most recent release v3.9.11 from 2026-07-09, so the code is being worked on and the releases are recent.

Where this is the wrong tool is a short list. If your library depends on APE tags, this editor will drop a leading one, and no configuration changes that. If you need a script to be safe by default, the command line is not, and you have to opt into force rewriting to get the behaviour the GUI has out of the box. If your work is on Ogg streams and you rely on padding to avoid rewrites, that path is documented as unsupported, even though it works for raw FLAC. And if you need to edit metadata in a format that is not on the list, there is no plugin mechanism described in the documentation, so the answer is a different tool.

The honest summary is that this is an unusually careful tag editor for the formats it supports, with the safety trade-offs documented rather than hidden, and a batch renaming utility and a translation set alongside the two front ends. For a library you care about, the plan is the same as the documentation suggests: let it rewrite, keep the temporary files until you are satisfied, and then clean them up yourself.

Editorial conclusion

Adopt Tag Editor if you batch-edit metadata across several container formats and you want a single tool that preserves what it does not understand, and if you can live with the fact that a write may rewrite the whole file. Do not adopt it if you need APE tag support, since that is explicitly not supported, or if you need the CLI to be safe by default, because the documentation recommends force rewriting for the command line. Before you run it in a pipeline, read the backup and temporary file section, keep the temporary directory on the same filesystem as the media, and decide deliberately whether you want padding, because the options that avoid rewriting a file also remove your safety net.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Martchus/tageditor on GitHub
4. README
5. Releases