JUST TAG — how it works

What it does

JUST TAG opens a folder on disk, lists the audio files in it, and docks a tag editor next to them. You fix one file or three hundred, rename from the tags or pull tags out of the names, move things where they belong — and hear the track while you do it.

It reads and writes .mp3, .wav, .flac, .aif, .aiff, .m4a, .aac, .ogg, .opus and .wma — the same list every other tool in the suite uses, so JUST TAG and the Pre-Cue Finder can never disagree about what is in a folder.

Your Serato and Traktor data comes back byte for byte

This is the part that matters if you have ever had a tagger eat a night's work, and it is the one claim on this page that was measured rather than assumed.

On 2026-07-31 we ran 128 real writes — 16 write scenarios across 8 MP3s carrying GEOB:Serato Markers2, an 85,166-byte PRIV:TRAKTOR4 blob, Mixed In Key's fields and a POPM rating — through the writer JustPlay actually ships, and diffed the files frame by frame with a hand-written ID3v2 walker.

787 of 787 vendor frame payloads survived byte-identically. Zero bytes lost. The audio stream was byte-identical in 128 of 128 writes, and running the same write two or three times over produced bit-identical files from the second one on.

On the same files, another widely used tagging library had earlier been measured cutting GEOB:Serato Markers2 from 470 bytes to 356, taking 515 bytes off the Traktor blob, renaming Mixed In Key's frames so MIK could no longer find them, wiping the POPM user string and force-upgrading ID3v2.3 tags to v2.4. Ours changed none of that.

What we do write

The editorial fields — title, artist, album, album artist, genre, year, track number, comment — and, separately, the three measurements you can correct by hand: BPM, key and energy. They are two different writes on purpose, and each one runs only if that half actually changed, so correcting a key cannot disturb a cover and fixing a title cannot disturb a Serato frame. Everything else in the file is re-emitted exactly as it was.

What this does not prove

Honest limits, because a page that names its own is worth more than a bold one:

The measurement is MP3 with ID3v2 tags only. FLAC, AIFF, WAV and MP4 were not tested.
There is one known residual risk, and it is reachable only from JUST TAG: converting a file's ID3v2 version re-serialises the whole tag, which re-encodes the labels on GEOB frames. No vendor byte is lost — but Serato and Mixed In Key look their data up by that label, so the data can become unfindable while nothing looks broken. See the write-format setting below: the default converts nothing, and the raw-tags window warns you when a conversion would actually affect a file.
We preserve bytes; we do not read them. We do not decode Serato's cue points, loops or beatgrids, and nothing in JUST TAG will ever claim to. A row says GEOB:Serato Markers2 — 470 bytes, which is a measurement. "Cue 3 at 2:14" would be a claim we cannot stand behind.
Byte preservation is a property of the tag library's current behaviour, not a promise it makes. The corpus is kept as a regression test so a library upgrade has to re-earn the number.

It browses the disk, not a library

Folders on the left, the files in them in the middle, the editor on the right. That is deliberate: this is the tool you reach for when a download just landed somewhere no index has ever seen. A playlist shows up in the folder pane as a folder you can step into, and a folder with nothing below it opens its files without descending, so you never land in a pane containing only "..".

When the folder does sit inside an indexed library root, JUST TAG fills the table from the machine's local index instead of opening every file — and says so under the file count ("412 from the library index — 6 read from disk"), so "why was this folder instant and that one slow" is answered on screen rather than guessed at. Nothing is written next to your music either way.

It opens where you left off, or on the folder you launched it on, or on your library root — and an unmounted share falls through to the next candidate instead of turning into an error at startup.

The track table — the same one, everywhere

The file list is the shared suite table: the same rows, the same widths, the same key pill and the same click-to-sort headers as the JUST PLAY queue and the Pre-Cue Finder, with JUST TAG's own columns switched on. Right-click the header to choose them.

AN — the analysis light

Grey: no JustPlay analysis in the file. Yellow: analysed with an older detector — the values are real, just older. Green: current. It is a report, never an instruction; nothing re-analyses on its own.

COV — is there a cover

A tick per file. A wrong or missing cover is invisible in a list of text, which is why it has a column of its own.

ID3 version

What the file actually carries — 2.3, 2.4, or nothing at all. The one file fact that decides whether a car stereo reads your tags, and it is not visible anywhere else.

The rest

Artist, album, album artist, genre, year, track number, comment, BPM, key, energy, file type, length and the file name. Your choice is remembered.

JUST TAG shows analysis; it does not run it. Detecting BPM, key and energy is JUST PLAY's job and the CLI's — one tool, one job, and this one carries no audio analysis at all.

Find the damage — the search

One search, not two. It starts on All fields, so typing something just works; pick a single field when you need to be exact. Sixteen fields — every editable tag, plus the ones you cannot see by looking at a name: whether there is a cover at all, which ID3 version the file carries, and the file type.

Seven ways to compare: contains, does not contain, is, is not, starts with, is empty and is not empty. "Genre is empty" is the one that finds the damage; "ID3 version is not 2.3" is the one that needs no query language. A second condition can be switched on and joined with AND or OR when one is not enough, and Include subfolders widens the search to everything below the folder you are standing in.

One file, or three hundred

Select more than one file and the editor keeps its shape — every field just grows two controls inside the box: a tick on the left and an X on the right.

The tick means this field takes part in the save. Untick it and the box is read-only, because a box that cannot be written should not invite typing into it.
The X empties the field — and emptying is an intent, so the X ticks the field itself.
One rule covers everything, the cover picture included: ticked and empty means "clear this on all of them".

A field the whole selection already agrees on starts ticked and shows that shared value, editable in one go. A field where they differ starts unticked and empty, so nothing gets flattened by accident.

Look before you leap

A multi-file save shows you what it is about to do first, as a list: this field, set to this value, on every selected file — plus a line each for the cover, the rename pattern and any fields being filled from file names. "Write to 37 files?" is a question nobody can answer; the list of fields and values is the thing you are actually agreeing to.

Values that are being cleared are called out separately, because emptying a field is the one setting that loses data outright.

Names and tags, one language, both directions

%artist% - %title% read one way builds a file name out of the tags. Read the other way it pulls tags out of the file name. It is one pattern language with one definition, because a placeholder that means "artist" while renaming must not mean something else while parsing.

A pattern can reach into the folders as well — %album%/%track% - %title% — which matters for a library filed as .../Hard Techno/Perc - Gob.mp3, where the genre lives in the path and nowhere else. %dummy% matches something and throws it away, for the track number you do not want. A cheat sheet window lists the whole language with worked examples, one keystroke from the box.

Tags from names — it tells you how many fit

As you type the pattern, JUST TAG counts your selection against it and says "fits all 37" or "fits 24 of 37". Files whose names do not fit the pattern are left exactly as they are — never filled with whatever a loose pattern happened to capture.

Matching is strict first and forgiving second: the exact form gets first refusal, and only a name that does not fit at all is offered the tolerant pass, where a hyphen may also be an en or em dash and an underscore may be a space. That order is what reads AC-DC - Highway correctly instead of making the artist "AC".

Renaming — previewed line by line

The rename preview shows every file as it is called now and as the pattern would call it, and names the problems in plain words: two files would get this name, that name is already taken here, the tags this pattern needs are blank, this name does not fit the pattern — left alone. Nothing is renamed until you save, so the result is visible and editable first — and one click puts the file's real name back if you change your mind, without throwing away the tag edits you already made.

Transform — fixing the text that is already there

The multi-file editor sets a field to one value. Transform changes the value each file already has: Replace (take the site name out of every comment), lowercase, UPPERCASE, Title Case, Sentence case, and Tidy — which collapses runs of whitespace into one plain space and trims the ends, catching the tabs and non-breaking spaces a copy-and-paste out of a web page leaves behind.

Nothing happens until Apply, and Apply cannot be reached without the preview. The preview lists one line per file per field — before and after — so a pass that touches both the artist and the title of the same file cannot hide half of what it is doing. Files that would not change are not listed at all, and the count line says so: "37 selected, 14 change" is one sentence rather than something to count. There is no undo, which is exactly why the preview is not optional.

Title Case is deliberately dumb. Every letter is lowercased, then capitalised when it starts a word. No dictionary of exceptions, no acronym guessing. So PERC - GOB becomes Perc - Gob (the case it exists for), don't survives, and VIP comes back as Vip. The way back is the operation sitting next to it: Title Case, then Replace Vip with VIP. Two passes, both previewed, both predictable — better than clever in a way you cannot predict across 400 files.

Move, copy, delete — and never overwrite

Tagging a folder usually ends with putting the files somewhere. Move to…, Copy to… and Delete… all work from the row, and all three show a plan before anything happens: how many files run, how many megabytes, how many are left alone and why.

There is no overwrite

Not a default, not an option. A destination that already holds the name is a collision: it is named in the preview, and the answer is either to leave both files alone (the default) or to keep both under a free name. Overwriting a track is unrecoverable, and a DJ finds out on a Friday night.

Delete means the recycle bin

Always. On a system with no reachable recycle bin, delete refuses rather than removing a track for good.

A move across drives is verified

Copy, verify, then remove — in that order. The copy lands under a temporary name with no audio extension, is checked against the original with a SHA-256 digest and its length, and is only then renamed into place. The original goes only once its bytes are confirmed at the other end.

A failure never stops the run

The file is recorded by name and the next one starts. A cancelled run still reports what it did — "8 of 40 moved" is information you need. Whatever had already finished stays finished.

Raw tags — see what is really in the file

Raw tags… opens every frame and field a file carries, exactly as it sits on disk: not the handful a tagger maps onto boxes, but all of it — including the frames that belong to other tools. It is read-only by contract; the window cannot write, and a test proves the file's SHA-256 is unchanged after it has been read.

Rows are addressed the way the DJ world already names them — GEOB:Serato Markers2, PRIV:TRAKTOR4, TXXX:EnergyLevel. Text frames show their text; binary frames show their size. Chips along the top count what each recognised vendor has in the file. They are counts, not a green light: a count is a measurement, and this window is not in a position to hand out verdicts.

This is the answer to "is my Serato data still in there after JustPlay touched it?" — you do not have to take our measurement's word for it, you can look.

The ID3 write format — and why the default converts nothing

MP3s in the wild carry different ID3v2 versions and text encodings, and which one a file has decides whether Windows Explorer, an old car stereo or a CDJ can read it. JUST TAG is the one place in the suite that can change it.

Keep the file's version: The default. Convert nothing: a file keeps the version and encodings it already has, and only the fields you edited are touched. A file with no ID3v2 tag at all gets a fresh v2.3 / UTF-16 one.
ID3v2.3 + UTF-16: Maximum compatibility — mp3tag's default, and the combination Windows, media players and older car and DJ hardware read reliably.
ID3v2.3 + Latin-1: For the oldest gear that chokes on a UTF-16 byte-order mark. ASCII-safe text only.
ID3v2.4 + UTF-8: Modern and compact — only for software you know reads v2.4.

Converting is a decision, not a side effect of pressing Save. The three converting modes re-serialise the whole tag, which re-encodes the labels on GEOB frames. Serato and Mixed In Key find their data by that label. The cue points stay in the file — those apps can stop finding them. The raw-tags window raises this only when it genuinely applies: the chosen format has to differ from that file's actual version and the file has to carry a frame that is addressed by a label at all.

Listen while you tag

There is a small player at the bottom of the panel: load, play, pause, seek, volume. Most taggers have no playback at all and hand the file to whatever the operating system has registered, which means leaving the tagger to hear the track you are tagging. We already have an engine, so the ear lives in the pane.

It stays a preview — no queue, no crossfade, no DSP rack. JUST PLAY is the player. And a file being previewed is a file with an open handle, so the preview releases it by itself when a save needs it: saving never has to be explained away.

Reading a big folder

Tags are read in the background as soon as a listing lands, several files at once, and the rows you are looking at fill first — a row scrolling into view jumps the queue, so you are not staring at blank cells while the tail of a 1,200-file folder catches up. Each file is read exactly once.

Navigation always wins. Switching folders cuts in immediately and drops whatever the previous one still had in flight. A progress line says "reading tags… 900 of 1,200" while it runs, and sorting and searching wait for the last row rather than quietly answering from the half that happened to be loaded. How many files are read at once is a setting — the same control, range and default as JUST PLAY's analysis threads, because reading tags waits on the network rather than on a core.

A listing's order is decided once, when it opens, and never changes under you a second later. A playlist is never auto-sorted at all: the sequence is the work.

Part of the suite

JUST TAG is a J.U.S.T. app, so it is the same window, the same six themes and the same track table you already know — and the editor docked on its right is literally the same editor that floats over the JUST PLAY queue and the Pre-Cue Finder. Written once, so the two cannot drift apart.

It installs alongside JUST PLAY, JUST STREAM and the headless CLI, sharing one copy of the runtime.