External sources and provenance

Three voices coexist in this program, and separating them is the core of the project:

• what the files say — the catalog, rebuilt from your folders with each scan;
• what you say — favorites, notes, ratings, and tags, in a file that a new scan never touches;
• what a third party says — MusicBrainz, Wikipedia, Fanart.tv, and the other explicit sources, in sources.json.

A value coming from a source sits alongside your tags and never overwrites them. Nothing is rewritten, nothing is merged, and every piece of data can be traced back to its author, dated, and removed. When a source and your tags disagree, both are displayed and doctor flags it — determining which one is right is beyond the scope of this program.

Querying MusicBrainz#

aede fetch                      # all artists and all albums
aede fetch manson               # only matching the name (artist or release)
aede fetch ~/Music/Alastis      # only what is on this shelf
aede fetch --dry-run            # show what would be requested without sending anything
aede fetch --full               # re-query what is already kept

A name and a folder correspond to two distinct questions, and fetch accepts both — see Restricting an execution by folder.

Artists and albums, in a single pass. Albums are the most important part: no tag indicates a musician's origin, so what MusicBrainz says about an artist can only be added alongside your library. It is different for an album — Picard records RELEASETYPE, DATE, and LABEL; so your files have an opinion, MusicBrainz has another, and the two can diverge. This disagreement is the reason for this storage model, and it applies to albums.

Date is the most common case. Your DATE tag says 1997 because that is the year of the reissue you ripped; MusicBrainz indicates that the album was first released in 1959. Neither is wrong, and Aède displays both rather than choosing one.

One request per album, regardless of your tags. If they contain the MusicBrainz album ID, the response arrives with certainty and brings the label in the same request. If they only contain the release group ID (release-group), the response remains certain, but without the label — a release group doesn't have one, and completing it with the label of the first matching pressing would attribute an edition's label to the album itself. If they contain neither, the album title and artist are searched, evaluated, and rejected below 70% instead of being guessed.

MusicBrainz allows one request per second; scanning a large library therefore takes time. The program displays the estimated duration before starting and asks for confirmation above 20 artists. It saves after each response, so an interrupted run loses nothing and a second run only costs the remaining requests.

Its search server sometimes returns a temporary 503 code, even when respecting the rate limit. The program waits — three attempts, with increasing delays — and stops only if the rejections persist.

HTTP 429 stops the pass immediately rather than entering the 503 retry sequence. Answers are limited to 32 MiB both before and after decompression, and invalid UTF-8 JSON is refused instead of silently changing source text. Completed work remains stored; an invalid response is a failure, not a cached absence.

A second run queries nothing it already possesses. --full allows re-querying, which is also required after an update that reads a field not previously stored:

aede fetch --full manson

Some artists return with no data stored, which confirms the system is working properly. A response that does not clearly concern your artist is ignored rather than guessed.

Prose Language#

Wikipedia enrichment retains the introductory REST summary, not every article section. A short biography therefore need not indicate a failed request. Its source URL, language and licence remain attached; Phémios can explicitly follow that exact title into its longer article reader. The text-extract API used there still omits some tables, references and media.

The summary is fetched in a single language and kept as such; the choice belongs to fetch and not to the subsequent display:

aede fetch --summaries                       # terminal language, English fallback
aede fetch --summaries --lang=fr             # French, English fallback
aede fetch --summaries --full --lang=fr ozzy # replaces already stored data
aede fetch --labels --summaries roadracer    # identify a label, then fetch its article

Without --lang, the terminal's LANG or LC_ALL variable is read (fr_FR.UTF-8 for French). English always remains the last resort, never excluded: for many artists, it is the only available article. The pass indicates what it is looking for before sending the request:

searching for articles in fr, en, in that order

An artist without a French article gets the English version, and the credit below the paragraph specifies the source read:

  https://en.wikipedia.org/wiki/Ozzy_Osbourne — in en — CC BY-SA 4.0
  aede fetch --summaries --full --lang=fr "ozzy osbourne" asks for another

This last line makes it possible to differentiate between an ignored preference, a non-existent article in your language, or data retrieved before setting a preference.

--full is necessary to replace text that is already stored.

Identified or Matched#

If your files went through Picard, they already contain MusicBrainz IDs, and fetch uses them: it queries the artist directly instead of searching for a name.

It is exact — the response concerns the requested ID, so the registry displays identified instead of a percentage. A percentage indicates search indexing quality, never that an artist is 88% correct.

And the response is more complete: a search result is abbreviated, whereas a direct lookup returns the full entity — current band activity or the disambiguation line used by MusicBrainz to distinguish homonymous artists.

Without an ID, the name is searched and the result comes with a score. Below 70%, nothing is saved, and two equivalent answers are rejected rather than arbitrated:

? Nirvana: several answers are equally good: Nirvana, Nirvana (UK)
? Sh: the closest was "Shellac" at 61%, not close enough

An approximate match is stored as evidence, but it is not a graph identity until you decide it is the right one. Exact MusicBrainz answers that contradict an identifier already present in your tags follow the same review path:

aede review                         # unresolved claims
aede review --interactive           # compare and decide one claim at a time
aede review manson                  # narrow them by entity name
aede review --accept=<ID>           # trust this exact claim
aede review --reject=<ID>           # keep it visible, but never traverse it
aede review --undo=<ID>             # return the decision to pending
aede review --all                   # include accepted and rejected claims

The interactive view shows the local identity and the source proposal before asking for a decision. Use A to accept, R to reject, S to leave the claim pending, P to go back, U to undo an existing decision, and Q to stop. Every decision is saved immediately, so an interrupted session can simply be resumed.

Acceptance never changes matched 92% into identified: the original confidence remains visible. It only records that you approved this precise entity/source/identifier tuple for navigation and queries. A different candidate returned by a later fetch needs its own decision. Rejection is not deletion, and every choice can be undone.

Secondary summaries, discography and artwork follow only exact identities or claims explicitly accepted in review. Pending and rejected candidates cannot become certain through another pass, and discography enrichment preserves the original match score. Equally ranked homonyms with different MusicBrainz IDs are refused even when their names match exactly; the explanation includes their IDs. Imports refuse malformed source tables and duplicate keys. An unreadable confidence value stays visible as matched 0% for review instead of becoming identified.

Manual Corrections#

Retrieved values are not the final word. Records are indexed by (entity, source), which means anything you classify under your own source won't be overwritten by MusicBrainz: a subsequent aede fetch --full will add its line next to yours without touching it.

Generate a document with the right keys:

aede sources --template --source=manual --output=fix.json "Kind of Blue"

Fill in the desired fields (null if data is missing):

{
  "entity": "release:miles davis|kind of blue|/Users/you/Music/Miles/Kind of Blue",
  "source": "manual",
  "facts": {
    "primary_type": "Album",
    "first_released": "1959-08-17",
    "label": "Columbia",
    "secondary_types": []
  }
}

Import it:

aede sources --import=fix.json

--source=manual protects this entry. Any name works (manual, yours, discogs…), the key being to avoid musicbrainz, as a source only replaces what it previously stated.

When the correction and the review decisions must be repeated on another Aède catalog, export the rules rather than the whole fetched source layer:

aede rules --export --output=rules.json
aede rules --import=rules.json

The versioned bundle includes manual source records, accepted or rejected source identities and exact credit exclusions, together with the personal filing and relationship rules. Import merges those choices; it does not copy biographies, artwork, listening history, or change any audio file. Use aede export --graph when the goal is instead to preserve every catalog, source and user layer for analysis.

Viewing and Deleting#

aede sources                    # one line per source: how much, how much lands
aede sources --list             # every record, and whether the catalog places it
aede sources --export --output=backup.json
aede sources --forget --source=musicbrainz
aede review                     # ambiguous identities needing a decision

aede artist and aede album display a "What sources say" block, matching each value against your tag:

  Source                        Field           Says        Your tags
  ────────────────────────────  ──────────────  ──────────  ────────────────────
  musicbrainz 88% · 2 days ago  release type    Album       nothing in your tags
  musicbrainz 88% · 2 days ago  first released  1959-08-17  matches your tags
  musicbrainz 88% · 2 days ago  label           Blue Note   Columbia
  musicbrainz: https://musicbrainz.org/release-group/c9fdb94c-…

The last line indicates the source address of the response, one per source. This identifier is essential for any manual verification — opening the page, running the request with curl, or fixing data at the source.

sources --export retains review decisions and credit exclusions even when their cached records have gone. sources --forget also removes those retained decisions, with an optional --source filter. Choose a single list/export/import/template/forget operation; --source is meaningful only for list, forget, and template. Human-readable prose, review cards and paths display terminal controls literally; saved source documents and machine exports keep their original values.

Supported artist, release, track and label snapshots require a facts object in both supported document versions. An absent, null, scalar or array-valued container is refused before replacing any retained record. An empty object {} remains a valid deliberately empty snapshot; inner optional fields retain their existing meaning. Unknown or unsupported entity kinds keep their existing ignored behavior.

Imports also refuse unreadable present credit/work collections in a recording or edition snapshot explicitly marked relationships_complete:true, including nested work credits. They do not replace the previous snapshot. Absent optional collections, valid empty arrays and legacy snapshots without that completion marker retain their existing meaning.

Completed recording-credit lookups may also carry relationships_for, the MusicBrainz recording selector whose completed lookup confirmed the retained canonical identity. This optional provenance distinguishes an unchanged alias redirected to a canonical ID from a later correction of the local recording ID. Reuse recognizes both that captured alias and the canonical ID returned by its lookup; retagging a file with the already confirmed canonical ID does not repeat the request. Explicitly refreshing that same canonical recording retains the earlier verified alias, while a different queried alias or unrelated corrected identity does not inherit it. A completed MusicBrainz snapshot whose canonical recording matches its source ID can also establish that captured alias during identity checks. The same proof governs whether its alias suppresses another lookup: missing or contradictory canonical recording facts remain retryable instead of establishing a completed alias. Two contradictory present selectors cannot complete the principal-ID lookup either. A legacy snapshot carrying only one selector remains reusable under that principal identity, without gaining an alias. Credit-coverage reports apply the same coherence rule, so a contradictory richer snapshot cannot conceal a valid answer from another placement. When only the recording fact retains an ID, it still participates in local identity conflicts and in preserving acceptance/rejection through a verified refresh or redirect. It does not upgrade a name match or override rejection; either explicit review follows only a verified continuation of that identity. Older snapshots remain readable and use their source ID as the lookup receipt until refreshed, without inventing missing alias evidence.

An exact MusicBrainz artist lookup redirected from a merged MBID may retain lookup_mbid in its artist facts. The source ID stays canonical; the optional captured alias allows the local tag to keep referring to the verified original identifier. This does not accept approximate name matches or unrelated IDs. Explicit acceptance or rejection remains authoritative and follows only a verified continuation of that artist identity. Older snapshots without alias evidence keep the existing conflict check until explicitly refreshed.

Label facts may also retain a verified optional lookup_mbid alongside the canonical source ID. Both the queried alias and the canonical identity remain usable after cache reload or retagging. Completing a name-search result keeps its original score; an exact lookup of that candidate does not accept the original name match. Acceptance/rejection follows only a verified continuation, including older snapshots stored under either confirmed ID. Unrelated decisions are not transferred.

Secondary artist-biography and label-Discogs lookups keep the same canonical/alias proof and original confidence, while preserving the reviewed decision and separately cached discography. They query a current tag only when it is already a confirmed equivalent of the source identity; a contradictory local tag cannot silently redirect an accepted source lookup. These optional fields do not require a storage-format migration; legacy caches are confirmed on an explicit refresh rather than having missing proof inferred.

Direct release-group lookups keep the canonical source ID and an optional verified lookup_mbid in release facts. Both the queried alias and a later retag to that canonical group remain usable, and a verified continuation retains acceptance/rejection. An edition lookup never establishes a group alias; completing the same group's edition credits preserves earlier proof. Legacy snapshots without this optional field remain readable and conservative until refreshed. Unreadable group identifiers in lookups, searches or nested edition responses are refused before replacing retained facts or decisions. Valid search candidates are ranked after unusable identifiers have been discarded; a failed refresh remains eligible for an explicit retry.

Exact edition lookups retain the returned canonical edition_mbid and, when redirected, an optional edition_lookup_mbid for the verified queried alias. Both identifiers reuse the saved credits after cache reload or retagging, and an explicit canonical refresh retains earlier alias evidence and acceptance/rejection. Without a group, the source ID is the canonical edition as well. Another edition, a release-group alias or a missing identifier cannot inherit these credits; manual corrections keep their literal scope. Legacy snapshots without this optional provenance remain readable and conservative until explicitly refreshed.

The ID is included in the URL and can be copied separately. An album address points to its release group, which defines the album as a whole rather than a specific pressing.

Three distinct states are differentiated: a value confirmed by your tags, a value in contradiction, and a value missing from your tags.

Two labels deserve clarification:

• from corresponds to the geographical area according to MusicBrainz (country, city, or region).
• note corresponds to disambiguation, written to distinguish homonymous artists.

Secondary Passes and Combined Runs#

Running aede fetch alone queries MusicBrainz for your artists and albums. Options enable complementary passes over the identified catalog:

aede fetch --summaries      # the Wikipedia article behind each wikidata link
aede fetch --discography    # everything MusicBrainz credits to each artist
aede fetch --lyrics         # missing words from LRCLIB, as .lrc sidecars
aede fetch --covers         # the front image of every album that has none
aede fetch --portraits      # Wikidata first, then Fanart.tv as fallback
aede fetch --labels         # identify record labels through MusicBrainz
aede fetch --credits        # recording/work credits and exact-edition credits, where IDs exist
aede fetch --logos          # artist and identified-label logos from Fanart.tv
aede fetch --fanart         # every supported Fanart.tv image family

--credits never searches by title: it follows only a MUSICBRAINZ_RECORDINGID attached to a local recording or a release ID on a local edition. A recording lookup keeps direct roles, linked works and their creative roles. A separate edition lookup keeps release-level artist credits, without assigning them to every recording. The pass preserves details such as credited-as spellings, instruments and qualifiers, dates, ordering and relationship identifiers. Existing data fetched with the former --recordings option is refreshed once into this richer form; --recordings continues to work as an alias.

When a linked work includes an explicit MusicBrainz part-of-work relationship, its parent identifier, title, movement/act qualifier and order are retained with the same source and trust boundary. aede work <parent ID> and query work:<parent ID> can then reach locally held movements. Work/grouping and movement tags stay local and are shown separately; they do not establish a parent identity on their own. An already completed recording lookup is not automatically re-requested just for this addition: use aede fetch --credits --full <album folder> to refresh a chosen edition.

To see which recordings and editions still need a credit lookup, run aede credits, then aede credits "<album>". This read-only report distinguishes an unanswered lookup (waiting) from a completed answer with no credits (empty) and from credits attached to untrusted source evidence (untrusted). Canonical recordings and local editions are counted separately: a recording shared by several editions does not establish their edition credits. Each edition needs a completed trusted answer for its exact local release ID. Manual edition credits are reported separately without claiming a MusicBrainz lookup. The album detail suggests a folder-scoped fetch command for either waiting scope; records without the required local MusicBrainz identity must be identified first. aede doctor also recognizes a trusted completed recording answer on another local placement, including a completed answer with no credits. An older identification-only snapshot cannot keep that recording marked incomplete; rejected, pending or internally contradictory snapshots cannot clear the diagnostic. Existing recording JSON fields remain available alongside the added edition coverage. aede fetch --credits --dry-run shows pending requests for both scopes.

Once trusted credits are present, a contributor who is absent from local tags can be opened with aede artist <MusicBrainz artist ID>. The resulting card is explicitly source-backed: it navigates to locally held recordings and albums, and to the works carrying creative credits, without manufacturing a catalog artist. aede search <name> includes those contributors in a separate section; namesakes stay distinct by ID. Pending or rejected source claims do not create such a navigable identity.

Each accepts names and folders:

aede fetch --discography "pink floyd"
aede fetch --covers manson portishead      # a list is fine
aede fetch --summaries mika                # nothing here matches mika
aede fetch --lyrics ~/Music/Alastis        # that shelf, whatever it is called

A name targets an artist by name, and an album by title or artist.

Restricting an Execution by Folder#

All fetch options accept folders, following the same logic as check, playlist, and fingerprint:

aede fetch ~/Music/Alastis                 # the artists and albums on that shelf
aede fetch --lyrics ~/Desktop/test/Alastis # the words, for those tracks only
aede fetch --covers --lyrics ~/Music/80s   # several passes, one shelf
aede fetch ozzy ~/Music/80s                # that person, on that shelf

Any existing path on disk is treated as a folder; everything else is treated as a name. The run displays the folders taken into account before querying:

  only what is under /Users/you/Music/Alastis

Lyrics

Both criteria apply independently: name defines who, folder defines where.

A folder not scanned by the catalog is rejected:

no file in the catalog is under "~/Music/New".
It is on disk, so this catalog was scanned 3 days ago and has not seen it — a folder added since is not in it yet.
Add it: aede scan "~/Music/New"

Options can be combined and execute sequentially:

aede fetch --covers --discography          # both, in one go
aede fetch --summaries --discography --covers --dry-run

Execution order follows a centrifugal logic starting from the artist: identity, discography, visuals.

Querying Wikipedia#

MusicBrainz does not store full biographies, but keeps a link to them. Fetching them is an option of fetch:

aede fetch --summaries          # follow it, for every artist already fetched
aede fetch --summaries --full   # ask again about what is already held

→ 402 stored, 3 left alone, 0 failed
  381 of them have a wikidata link — aede fetch --summaries reads the article

The summaries pass first completes missing detailed MusicBrainz links for already trusted artist identities. An abbreviated accepted name-search result can therefore obtain its Wikidata link without being promoted to identified or losing its original score/review. Valid empty relationships are cached distinctly from legacy incomplete claims; failed/malformed requests remain retryable. Use --summaries --artist-ref=artist:example for one exact local artist, without names/folders or other passes. The graphical source-review contract exposes the same durable decisions to administrators.

This is a second pass on fetch data, not a new Wikipedia name search. The program reads an artist's or label's wikidata link, queries Wikidata to get the corresponding article, then retrieves the first paragraph from Wikipedia (two queries per entity). fetch --labels now asks MusicBrainz for each label's Wikidata link. A label fetched by an older Aède version can be refreshed with aede fetch --labels --full <name> before aede fetch --summaries <name>. When MusicBrainz has no Wikidata link, or Wikidata has no article in the requested languages, that pass has no Wikipedia biography to show.

Only standard Wikipedia article summaries become biographies; disambiguation and non-article responses are left alone. Wikidata links must point to Wikidata itself. For portraits, usable preferred P18 statements take precedence over normal ones; deprecated or missing-value statements do not hide a later usable image.

For a label with no Wikipedia biography, opening its page checks the Discogs link on its MusicBrainz record:

aede label roadracer

The Discogs profile is kept in sources.json with its source, page and fetch time. Opening the page checks the current profile and replaces the stored copy if available. --offline skips the request. When a check fails, the label page shows the stored profile with an update notice; --offline also shows that notice when the copy is older than five hours. Other source views and exports still hide a profile that old. Aède verifies the Discogs label ID and name and never searches Discogs by name. Discogs label references such as [l30552] and artist references such as [a1258936] are resolved to their names independently of the local catalog; presentation tags such as [b] are removed. An already stored profile with unresolved artist codes is reprocessed on the next successful visit. The original profile is normally English: Discogs does not supply a French version of that field, even on its French site. The display includes “Data provided by Discogs.” and the source page. Discogs' API terms limit how old displayed data may be, so the offline fallback has a compliance limitation when a refresh is unavailable for a long time.

The label page preserves Discogs line breaks and blank lines between paragraphs, and emphasizes the label-code line when terminal styling is enabled. Long lines are wrapped without merging the paragraphs. This layout also applies to already stored profiles, including offline display.

Articles are searched primarily in the system language (LANG variable), then in English.

Credit is Part of the Text#

Wikipedia articles are licensed under CC BY-SA. Using the text requires citing the source and license. Aède stores the paragraph, page, language, and license as an inseparable value:

  Marilyn Manson is an American rock band formed in Fort Lauderdale,
  Florida, in 1989.
  https://en.wikipedia.org/wiki/Marilyn_Manson_(band) — CC BY-SA 4.0

aede sources --forget --source=wikipedia deletes the whole set.

Images Already Present in Your Files#

Before downloading anything, a local solution exists. An album without a cover.jpg file in its folder can extract its visual from inside the audio files:

aede extract                    # write it out, everywhere it is missing
aede extract ~/Music/Manson     # only under these folders
aede extract --images           # the back and the booklet too, in artwork/
aede extract --dry-run          # say which folders, write nothing

The program reads your files without ever modifying them. No writing occurs inside audio files. The image is created alongside (folder, playlist, spectrogram). Works across all formats (FLAC, ID3, MP4, Ogg).

Extraction runs per folder. A folder that already contains an image is skipped.

Other Embedded Visuals#

In addition to the front cover, --images extracts back cover, booklet, or disc into an artwork/ subfolder so as not to interfere with front cover detection by media players:

/music/Miles Davis/Kind of Blue/
    cover.jpg
    artwork/
        back.jpg
        booklet-01.jpg
        booklet-02.jpg
        media.jpg

Album Cover Art#

Retrieving visuals from Cover Art Archive (MusicBrainz).

aede fetch --covers                 # albums with no cover, at 1200 px
aede fetch --covers --size=500      # 250, 500, 1200 or original
aede fetch --covers --images        # the back and the booklet too, in artwork/
aede fetch --covers --dry-run       # say which albums, ask nothing

Run aede extract first. --covers only downloads if no image is present (neither embedded nor in the folder). There is no --replace flag to prevent accidental overwrites.

Downloaded images are saved as cover.jpg or cover.png alongside audio tracks. Audio files are never altered. JPEG and static PNG pixels are decoded before publication, with complete container endings required. Incomplete containers, undecodable pixel streams and animated PNG are refused. Images are limited to 32 MiB, 8192 pixels per axis and 16 million pixels; no external image tool is required. PNG checks include chunk CRCs and the compressed stream checksum. JPEG has no integrity checksum: a modified stream that remains decodable cannot be certified as its original. --full re-queries the archive without replacing local images. Extra-image completion is recorded only when the whole answer succeeds: an existing artwork/ directory alone is insufficient, and retries skip images already saved.

Archive receipts retain their exact release or release-group index URL in source_id, including negative answers and completed extras. Changing that identity reopens the lookup; edition and release-group namespaces are kept distinct. Older receipts without that selector are confirmed once when a current identity is available. A failed confirmation preserves the previous evidence and remains retryable. Without a current identifier, a trusted stored front address remains recoverable; existing image files are never overwritten.

Fanart.tv Artwork#

Fanart.tv complements the Cover Art Archive with artist artwork, label marks, and additional album visuals. It requires a free application key in AEDE_FANARTTV_KEY:

export AEDE_FANARTTV_KEY="your-key"
aede fetch --fanart

--fanart enables every supported family in one pass:

Start from everything and remove only what you do not want:

aede fetch --fanart --no-logo
aede fetch --fanart --no-label-logo --no-banner
aede fetch --fanart --no-portrait --no-background
aede fetch --fanart --no-album-cover --no-cdart

The complete exclusion list is --no-logo, --no-label-logo, --no-portrait, --no-background, --no-banner, --no-album-cover, and --no-cdart. An exclusion without --fanart is refused instead of silently ignored. Contradictory requests such as --fanart --logos --no-logo or --fanart --banners --no-banner are refused as well.

The narrower forms remain available for compatibility and focused runs:

aede fetch --logos              # artist and identified-label logos only
aede fetch --logos --banners    # the same artist response also yields a banner

Each family has its own completion record. If backgrounds are excluded today, a later aede fetch --fanart --no-portrait can still fetch them without repeating image families already completed. --full deliberately asks again. Existing JPEG and PNG files are never overwritten. The same bounded full-image validation used for Cover Art Archive runs before publication, including artist assets, label logos, album covers and cdART. Animated PNG is refused. Validation failure does not create an output or mark that transfer as completed.

Missing from the Shelf#

aede fetch --discography    # browse everything credited to each artist
aede missing                # what is credited to them and not here
aede missing davis          # narrowed, by artist or by title

missing performs no network request. It calculates the result from stored discography data. A trusted cached group lookup can establish an old/new MusicBrainz alias pair for a local album carrying either group ID. Both sides then count as owned, before and after retagging. Edition fallbacks, pending/rejected claims, detached records and contradictory local identities cannot supply this equivalence. The literal group IDs in tags and the existing title fallback remain independent.

Missing

  Artist       Album              Year
  ───────────  ─────────────────  ────
  Miles Davis  Sketches of Spain  1960
  Miles Davis  Bitches Brew       1970
  2 studio albums
  9 records left out — --all lists them here, with the reason for each: singles,
  live records, compilations, demos, and anything you set aside

Exclude or Re-include an Album#

aede missing --forget "Sweet Dreams"            # stop listing it
aede missing --list                             # what you set aside
aede missing --list manson                      # narrowed, by artist or by title
aede missing --forget "Sweet Dreams" --remove   # put it back

Choices are saved in user.json and indexed on the MusicBrainz release group ID.

The default filter only keeps studio albums from artists having at least one complete album in the local library.

Identifying a File by Acoustic Fingerprint#

Acoustic fingerprint computed from decoded audio signal to identify mislabelled files or missing metadata.

aede fingerprint                # decode and work out what the audio is
aede fingerprint ~/Music/Rips   # only under these folders
aede fingerprint --full         # every file, not just the nameless ones
aede fingerprint --list         # print what is stored, to compare it
aede fetch --identify           # ask AcoustID what it hears

By default, properly tagged files or files already holding a MusicBrainz ID are skipped.

Comparison and Duplicate Detection#

aede doctor groups files sharing the same acoustic fingerprint to identify strictly identical recordings, regardless of their tags:

  ! the same audio — 2 files are the same recording (379.1 kB recoverable)
      /music/Copie/track07.flac
      /music/Original/01.flac

Prerequisites: Chromaprint (ffmpeg or fpcalc) and an AcoustID API key configured in AEDE_ACOUSTID_KEY. The system identifies and suggests matches, but never alters audio files.

What MusicBrainz Does Not Contain#

• No full biography (only type, area, dates, and disambiguation note are provided). Wikipedia/Wikidata fills this gap.

• No overwriting of your files: retrieved data remains independent of your original tags, and deleting sources.json does not affect your local files.