pub struct AudioFile {
pub id: Id,
pub path: String,
pub size: u64,
pub mtime: u64,
pub properties: AudioProperties,
pub has_embedded_art: bool,
pub tags: BTreeMap<String, Vec<String>>,
pub lyrics_path: Option<String>,
pub integrity: Option<IntegrityRecord>,
pub fingerprint: Option<Fingerprint>,
}Expand description
A file on disk, with its technical properties and its raw tags.
The raw tags are kept: they allow the whole graph to be rebuilt without rereading the files, which is what makes incremental scanning possible.
Fields§
§id: IdPosition in Catalog::files; this is what a track points back to.
path: StringAbsolute path in the scanner’s native spelling, including Windows
verbatim prefixes. Use text path helpers for catalog string operations.
size: u64Size in bytes; together with AudioFile::mtime and the catalog’s
Catalog::file_mtime_subseconds it decides whether a later scan can
reuse the stored tags.
mtime: u64Modification date, in seconds since the Unix epoch.
properties: AudioPropertiesDescription of the stream itself: codec, sample rate, duration.
has_embedded_art: boolWhether cover art sits inside the file; when it does not, the release may still carry an image found beside it.
Tags as read, lowercase name to values, kept so that the whole graph can be rebuilt without touching the disk again.
lyrics_path: Option<String>A .lrc sitting beside the file, when there is one.
The path, not the text. Lyrics carried by a tag are already in the catalog — raw tags are kept per file — but a sidecar is not in the file, and storing its contents as though it were a tag would make the catalog lie about what the file says. It is one small text file next to the music; reading it when somebody asks costs nothing and is always current.
integrity: Option<IntegrityRecord>What the last integrity check concluded, if one was ever run.
None means “not checked”, which is deliberately distinct from
audit::integrity::Verdict::NothingToCheck: the first can change, the
second cannot. The verdict travels with the file entry, so a scan that
reuses the entry keeps it and a scan that re-reads the file drops it —
a modified file has to be checked again.
fingerprint: Option<Fingerprint>The acoustic fingerprint of this file, once one has been computed.
Beside the integrity verdict and for the same reason: both are Aède’s own conclusions about the bytes, worked out rather than fetched, and both are expensive enough that recomputing them on every scan would be unthinkable. So both travel with the file entry — a scan that reuses the entry keeps them, a scan that re-reads the file drops them, because a modified file is different audio and its old fingerprint describes something that is no longer there.
What AcoustID says when shown one is a different kind of thing —
somebody else’s claim — and lives in sources.json with every other
source’s.