Skip to content

feat: write tags into DSD files (.dsf / .dff) #592

Description

@InstaZDLL

We index .dsf and .dff and we play them natively over DoP on three platforms, but we cannot correct a typo in one. edit.rs refuses them before touching the file:

lofty 0.25's FileType carries no DSD variant, so read_from_path on a .dsf / .dff fails with a generic "unknown format" — accurate, but it reads as a corrupt file rather than as a format we never supported writing. DSD metadata is parsed by waveflow_core::audio_format::dsd, which is read-only, so there is no fallback to reach for: refusing before we touch the file is the whole of the honest answer.

That refusal was the right fix for the honesty problem. It is not an answer to the capability problem, and the gap is pointed: native DSD is the headline of our audio story, and it is the one format whose tags we cannot touch.

What it needs

A writer of our own, because the dependency will not provide one. The reading side already exists — waveflow_core::audio_format::dsd parses both containers — so the container knowledge is in the tree; what is missing is its mirror image.

  • DSF carries an ID3v2 tag at an offset declared in the header. Writing means rewriting that tag and updating the pointer and the file-size field with it.
  • DFF has no ID3 by convention; metadata lives in its own chunk structure, and some taggers append an ID3 chunk. Decide which shape we write, and read both.

Traps

  • Nothing may be lost. The same rule the rest of our tag writing follows: frames and blocks we did not edit are copied through untouched, so correcting a title never costs a cover, a rating or a MusicBrainz identifier.
  • Cover art is addressed by content, not by index. Removing "the third picture" is how the wrong picture gets removed.
  • Pause playback before writing the current track's file, and re-hash after (invariant).
  • The refusal must stay until the writer is complete per format. Half-supporting DFF while claiming to support DSD would be worse than today's clear no.
  • Worth pairing with in-place writing, since a DSD file is large and a full rewrite of one is expensive.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestplannedPlanned for a future releasescope: audioAudio engine, playback, decoding, and output devicesscope: backendRust/Tauri backend (src-tauri/)type: featNew feature

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions