Guide
Audio Metadata and AI Music: What File Tags Really Prove
Before a detector touches the waveform, the file has already told you something about itself. Tag blocks, encoder strings and registration identifiers are the closest thing to provenance most people ever get — and they are also editable, strippable and routinely destroyed by ordinary uploads. This is how to read them properly, what each field actually means, and where the evidence stops.
· 12 min read
Why metadata comes before acoustics
Every acoustic detector, including ours, answers an indirect question. It measures how a recording behaves — where the spectrum stops, how tonal balance drifts between sections, how much dynamic range survived, how the stereo image was built — and infers from those behaviours whether the audio resembles the output of a generative pipeline. That inference is real evidence, and it is inference all the way down. There is no watermark to read, no signature to verify, no ledger to check.
Metadata is a different category of thing. When a file says it was written by a particular application, or carries a comment naming a model, or holds a recording identifier issued by a distributor, that is a written claim about origin rather than a statistical guess about sound. Claims can be false. They can also be checked, corroborated and traced in ways that a probability cannot. That asymmetry is why our recommended triage order puts documentation above listening, and listening above any score.
The practical consequence is simple: reading the tag block costs one click and sometimes answers the question outright. Skipping it and going straight to a percentage means you may have spent effort on a probabilistic estimate when the file was volunteering its origin in plain text. The habit is worth building even though it fails most of the time, because when it succeeds it succeeds completely.
- Acoustic analysis infers origin from behaviour; metadata states a claim about origin
- Claims can be wrong, but they can be corroborated — probabilities cannot
- Reading tags is cheap, fast and occasionally decisive
- Failing to find anything is the normal outcome and costs you nothing
Where tags actually live inside an audio file
Audio files are containers: a wrapper format holding compressed or uncompressed audio plus optional blocks of descriptive data. Each container family stores that descriptive data in its own way, which is why some tools read tags from one of your files and nothing from another. Understanding the four common shapes removes most of the confusion.
MP3 files carry ID3 tags, usually ID3v2 at the head of the file. Each field is a four-character frame identifier followed by text: TIT2 for title, TPE1 for artist, TSSE for the encoding software and settings, TENC for the encoding entity, TXXX for arbitrary custom key-value pairs. Older files may use three-character ID3v2.2 identifiers, or a fixed 128-byte ID3v1 block at the very end of the file.
MP4-family files — M4A, AAC and ALAC exports — store metadata in an atom tree, with the interesting fields inside an `ilst` atom. Their names often begin with a copyright symbol: ©nam for title, ©ART for artist, ©too for the encoding tool. FLAC and Ogg both use Vorbis comments: a vendor string followed by a list of uppercase KEY=VALUE pairs such as TITLE, ARTIST, ENCODER and DESCRIPTION. WAV, being a RIFF container, may carry a LIST/INFO chunk with four-character identifiers like ISFT for the writing software, and very often carries nothing at all.
None of these formats reserves a field for 'was this generated'. There is no standardised provenance slot in general music files today, which means any generator disclosure you find lives in a general-purpose field that happened to be filled in — a comment, a software string, a custom TXXX pair.
- MP3 → ID3v2 frames (TIT2, TPE1, TSSE, TENC, TXXX)
- M4A / AAC / ALAC → MP4 `ilst` atoms (©nam, ©ART, ©too)
- FLAC and Ogg → Vorbis comments (TITLE=, ARTIST=, ENCODER=)
- WAV → optional RIFF LIST/INFO chunk (ISFT), frequently absent
- No mainstream format has a dedicated AI-provenance field
The fields worth reading, in order of usefulness
Software and encoder fields come first. TSSE, TENC, ©too, ENCODER and ISFT record what wrote or compressed the file. Most of the time they name ordinary transcoding libraries — LAME, FFmpeg or its Lavf muxer, iTunes, qaac, flac, opusenc. Those names appear on human recordings and generated tracks alike, because nearly everything gets re-encoded on its way to a platform. Occasionally these fields name an application specific enough to be a real lead: a generator's own exporter, a stem-separation tool, a voice-conversion utility.
Comments and descriptions come next. Free-text fields are where people write things the format never anticipated, including the prompt used to generate a track, a tool name and version, or an explicit disclosure. They are also where automated export pipelines sometimes leave templated strings. When a comment names a generator, treat it as the strongest signal on the page — and still as a claim.
Recording identifiers matter for a different reason. An ISRC means the recording passed through a distributor or label workflow, which is precisely where AI-involvement questions are asked and answered as part of release metadata. The identifier itself says nothing about generation, but it tells you that a documented trail exists somewhere, and that trail is more authoritative than any acoustic measurement.
Finally, the mundane fields — title, artist, album, dates — matter mostly as consistency checks. A release date that predates the artist's catalogue, an album name that does not match the store listing, a date stamp inconsistent with the claimed recording history: these are the small mismatches that turn out to be informative more often than any single number does.
- Encoder and software fields: what wrote the file, usually mundane
- Comment and description fields: where disclosures and prompts end up
- ISRC: proof that a distributor workflow exists, not proof of origin
- Titles and dates: check them for internal consistency, not for truth
What destroys metadata, and why absence proves nothing
The single most common result of a metadata check is nothing at all, and this surprises people who expect files to remember their history. They do not. Metadata is discarded aggressively by almost every path audio takes between creation and a listener.
Streaming platforms and stores re-encode uploads into their own delivery formats, which rewrites the container and typically discards software fields. Messaging apps re-encode harder still, often at low bitrates, and produce files with no descriptive block. Screen recordings and phone captures create entirely new files whose only metadata describes the capture device. Stem exports and WAV bounces from a session frequently start with no tag block, because the exporting application never wrote one. Even simple format conversion drops any field the target container has no slot for.
So the correct reading of an empty tag block is: this file has been through at least one ordinary processing step. That is all. It is not evidence of concealment, and it is not evidence of generation. Anyone who tells you that stripped metadata is suspicious is inverting how the ecosystem actually works — stripped metadata is the default state of nearly every file in circulation.
The mirror-image error is also common: assuming that surviving metadata is trustworthy because it is technical. Tag fields are text. They can be rewritten in seconds with free tools, and there is no signature protecting them. A file claiming human authorship proves nothing, and a file naming a generator could have had that name added by anybody who touched it.
- Platform transcodes rewrite containers and drop software fields
- Messaging apps, screen recordings and re-captures produce metadata-free files
- WAV and stem exports frequently never had a tag block
- Empty metadata is the default, not a red flag
- Present metadata is editable text with no integrity protection
How to run the check without uploading anything
Our audio metadata checker reads the head of a local file directly in the browser using the file API, parses whichever tag block it finds, and lists the fields alongside a plain-language reading of what each one is worth. Nothing is transmitted, logged or retained — the same architecture as the detector itself, for the same reason: a tool that asks you to hand over a private mix in order to answer a question about privacy has already failed.
Practically, the sequence that works is: read the metadata first, then decide whether an acoustic test is still needed. If a field names a generator, you have a lead worth pursuing directly with whoever supplied the file, and a score adds little. If the fields are mundane or empty — the usual case — move to acoustic analysis knowing that you have exhausted the cheaper, stronger class of evidence.
Two habits improve the result. First, always check the original file rather than a copy you made, because your own download or conversion may be the step that stripped the tags. Second, record what you found before you look at a probability, exactly as you would write down your listening impressions first. A score anchors interpretation hard, including interpretation of text you have already read.
- Read the tag block before running any acoustic analysis
- Check the original file, not your own re-encoded copy
- Write down what you found before you see a percentage
- A generator name in a tag is a lead to pursue, not a conclusion to publish
Watermarks, C2PA and what provenance could become
There is a better world available in principle. Cryptographic content credentials — the C2PA family of specifications — attach signed assertions about how an asset was created, and those assertions survive checking in ways plain tags do not. Some generative image and video tools already emit them. Audio adoption remains partial, inconsistent across the tools people actually use, and vulnerable to the same stripping behaviour that destroys ordinary metadata, since a signed manifest is still a block of data a transcode can discard.
Inaudible audio watermarking is the other candidate. Some generators embed signals designed to survive compression and identify their output. Where those exist and where the corresponding verification service is available, they beat everything discussed on this page. But coverage is partial, verification is usually controlled by the generator rather than open to third parties, and any pipeline that resamples, re-encodes or re-records the audio may damage the mark. Treat a watermark hit as strong evidence and a watermark miss as no evidence at all.
Until one of these becomes universal and durable, the honest position is that provenance for music is a documentation problem, not a signal-processing one. The most reliable record of how a track was made is the one a person deliberately keeps: session files, prompt history, dated exports, stems, and an accurate answer in the distributor upload flow. Those artefacts do not degrade when a platform re-encodes the audio.
- C2PA content credentials are signed and checkable, but adoption in audio is partial
- A signed manifest can still be stripped by an ordinary transcode
- Generator watermarks are strong when present; absence means nothing
- Deliberately retained project files remain the most durable provenance
Combining metadata with an acoustic result honestly
Once you have both a tag reading and a score, the temptation is to add them into a single verdict. Resist it, because they are evidence about different things and they fail in different ways. Metadata speaks about the file; acoustics speak about the audio. A file can be freshly exported from a generator with pristine tags and produce a middling score. A human recording can be heavily mastered, produce an elevated score, and carry no metadata at all.
The useful framing is a small decision table. Generator named in metadata plus an elevated score is a coherent picture, and still not proof — ask the source. Generator named with a low score most likely means the audio has been through human editing, re-recording or heavy processing that erased the measurable behaviours; on our own measurements a re-encode shifts results by around 2.4 percentage points and analysing a different excerpt shifts them by around 4.4, and creative editing exceeds both by a wide margin. No metadata plus an elevated score is the ordinary borderline case where you report a range and a caveat. No metadata plus a low score is the case where you should say undetermined rather than human.
The last of those is where most misuse happens. A low probability is not a certificate of human authorship; it is the absence of the specific behaviours the analysis can see. Competent generated music, edited by a competent person, is designed to produce exactly that reading. Saying 'undetermined' is not a weaker answer than 'human' — it is the accurate one.
- Tags describe the file, measurements describe the audio — keep them separate
- Generator name plus low score usually means editing, not a mistake in the tag
- No metadata plus a low score means undetermined, never 'human'
- Report ranges and inputs, not verdicts
If you are the one publishing the track
Everything above describes the position of somebody investigating a file. The position of somebody releasing one is easier, and better, because you control the record. Answer the AI-involvement question accurately in your distributor's upload flow, because that answer is the field that travels into store metadata and becomes the industry-visible statement about your release. Keep your credits accurate for every human who contributed. Where a platform asks separately — YouTube's altered-or-synthetic disclosure, for example — answer there too.
Then write your own tags. Filling a comment field with a one-line description of how the track was made costs nothing, survives longer than you might expect on direct-download paths, and makes you the source of your own provenance rather than leaving it to somebody's inference from a spectrum. Our disclosure generator will assemble the wording for a distributor field, a credits note, a video description or a release page.
Finally, retain the underlying material. Sessions, prompt logs, stems, dated bounces. Almost every public dispute about AI involvement in music turns on a mismatch between what metadata claims and what credits or context suggest — and the party who can produce a dated trail ends those conversations quickly. No detector, ours included, can do that for you.
- Answer the distributor's AI question accurately — that field becomes industry metadata
- Write a plain description into your own comment tag before export
- Use platform-specific disclosure toggles where they exist
- Keep sessions, prompts, stems and dated exports
The short version
Read the file before you read the waveform. Tag blocks, encoder strings and recording identifiers are the only claims about origin a file can carry, and they answer the question outright often enough to be worth one click. Expect them to be missing, never read absence as concealment, and remember that neither a tag nor a probability is proof — the durable record is the documentation a person chooses to keep.
Try the free AI music detectorFrequently asked questions
Only in the limited sense that a file can carry a written claim about its own origin, such as an encoder or comment field naming a generator. That is the strongest evidence a file can hold about itself, and it is still editable text with no integrity protection. Metadata can make AI involvement very likely; it cannot prove it, and its absence proves nothing at all.