Available today
A usable end-user capability exists in the distributable application.
Development status
What is available, what comes next, and what depends on compatibility work.
This page provides detailed lifecycle classifications for the workflows described across the site.
Lifecycle definitions
How to read availability.
Lifecycle labels describe the end-user experience, not the existence of a model, test, prototype, or screenshot.
In development
Material implementation exists, but the complete end-user workflow is not yet ready.
On the roadmap
The capability is an approved MMW commitment but is not currently usable.
Compatibility work
Feasibility or integration behavior depends on provider, hardware, protocol, licensing, external-tool, or platform validation.
Playlists and crates
Playlist and destination workflows.
Detailed availability for sequence inspection, reordering, files, packages, servers, devices, performance, and archives.
| Capability | Availability | What it does | What to expect |
|---|---|---|---|
| Plex server discovery | Available now | Broker-authorized Plex profiles can be discovered for read-only playlist review. | Discovery does not imply server writeback. |
| Plex authorization | Available now | Plex access is handled through a central authorization flow so credentials are not scattered through the interface. | Tokens remain local application material. |
| Plex playlist discovery | Available now | Plex playlists can be listed and brought into the review workspace. | Discovery is read-oriented. |
| Playlist import | Available now | Playlist snapshots can become ordered rows for review and comparison. | Import creates review data, not a server update. |
| Playlist inspection | Available now | Track title, artist, album, year, duration, source path, and order can be inspected together. | Visible fields depend on available source metadata. |
| Playlist ordering | Available now | Proposed positions, sort presets, grouping, and duplicate handling can be reviewed before delivery. | The reviewed order is not pushed to a server without a separate reviewed path. |
| Playlist reordering | In development | Reorder plans can be previewed while durable server updates remain a reviewed planned path. | Live server mutation is not presented as available. |
| Playlist difference report | Available now | Reports can show moved, unchanged, up, and down track counts. | Reports describe the plan being reviewed. |
| Proposed playlist review | Available now | Readiness, sort rules, missing paths, duplicate paths, duration, and proposed order can be summarized. | Review information supports a user decision. |
| Save back to Plex | In development | Plex save-back is being designed around authorization, resolved item identities, confirmation, and a prior-order record. | No live Plex writeback is claimed as available. |
| Prior-order preservation | In development | A server update path must preserve enough prior-order detail to support recovery. | A recovery record is a prerequisite for planned server updates. |
| Jellyfin planning | In development | Jellyfin connector planning is represented as a dry-run boundary for planned review. | No Jellyfin update is claimed as available. |
| Emby planning | In development | Emby connector planning follows the same reviewed-change model as Jellyfin. | No Emby update is claimed as available. |
| M3U and M3U8 preview | Available now | M3U and M3U8 output can be previewed as part of playlist preparation. | Preview does not mean a playlist file is written automatically. |
| Portable-device export | Planned | Portable delivery is planned around destination choice, capacity checks, format checks, manifest review, copy, and verification. | Automatic portable copy is not claimed as available. |
| Flash-drive delivery | Planned | Flash-drive delivery is planned as a reviewed folder and playlist package workflow. | Automatic sync is not claimed as available. |
| File copy and sync | Planned | Copy and sync work belongs behind destination review, conflict checks, and verification. | Current preview workflows do not perform file copy. |
| Capacity planning | Available now | CD, MiniDisc, and cassette preparation can use duration and capacity checks. | Capacity planning is separate from device control. |
| Codec compatibility planning | Available now | PCM readiness and extension review can identify likely format-readiness concerns. | A readiness warning is not a transcoding action. |
| Duplicate detection | Available now | Duplicate paths can be counted and reported during playlist review. | Duplicate review does not remove tracks without user action. |
| Missing-track detection | Available now | Missing and unverified paths can be reported before delivery planning continues. | Missing media must be resolved by the user or a later workflow. |
| Crate export | Planned | DJ crate language is part of the planned delivery vocabulary. | DJ crate output is not claimed as available. |
| DJ delivery package | Planned | DJ delivery is planned around a reviewed sequence, compatible files, and a destination package. | No automatic DJ-library update is claimed. |
| Karaoke delivery package | In development | Playlist-to-karaoke preparation is tied to lyrics, timing, and package validation. | Live karaoke output remains planned capability. |
| MiniDisc planning | Available now | MiniDisc, NetMD, Hi-MD, and label-sheet preparation can be modeled as review plans. | Direct transfer is not claimed as available. |
| NetMD transfer preparation | Available now | NetMD upload preparation can be modeled so titles, order, and capacity are visible. | Hardware access is not claimed as available. |
| Cassette side planning | Available now | C60, C90, and C100 side balancing can be reviewed with fit checks and J-card direction. | Recording control is not claimed as available. |
| Cassette recording sheet | Compatibility validation | Cassette recording sheets remain a preparation and presentation direction. | No deck control is claimed. |
| DAT sequence planning | Compatibility validation | DAT planning is a longer-range legacy-media direction for program order, duration, sample-rate readiness, cue sheets, and manifests. | No DAT-specific transport control is claimed. |
| DAT recording sheet | Compatibility validation | DAT recording sheets are planned as documentation of a reviewed program sequence. | No automatic recording is claimed. |
| Legacy-device cue timing | Compatibility validation | Cue, timing, and capacity preparation can guide planned device workflows. | Compatibility validation does not imply hardware integration. |
| Direct device transport control | Compatibility validation | Direct transport control remains a longer-range investigation after safety, driver, and feasibility work. | No direct hardware control is claimed. |
Providers
Metadata, lyric, artwork, and server providers.
A provider profile, a preview path, and a usable integration are distinct levels of capability.
| Source / provider | Role | Availability | How it helps | What to expect |
|---|---|---|---|---|
| Embedded tags and folder evidence | Local metadata, artwork, identifiers, lyrics, and sidecars | Available now | MMW can inspect local file and folder evidence without a network lookup. | Inspection does not authorize a tag, artwork, rename, move, or sidecar write. |
| AcoustID | Fingerprint-based recording identity rescue | In development | A guarded manual preview path can turn a local fingerprint into review candidates with cache, throttle, and provenance controls. | Lookup is user-initiated and read-only; credentials stay outside normal UI and no candidate writes tags. |
| MusicBrainz | Recording and release identity linked through AcoustID | In development | MusicBrainz-linked identifiers can appear in normalized AcoustID candidates. | There is no direct MusicBrainz client; direct release lookup remains planned. |
| Discogs | Edition-level physical release metadata and credits | Planned | A profile defines Discogs roles, credential needs, provenance, and candidate-review boundaries. | Profile-only: no live Discogs lookup is presented as available. |
| Cover Art Archive | MusicBrainz-release artwork candidates | Planned | Artwork lookup is modeled after a release identity is established. | Profile-only; candidate comparison, attribution, and compatibility review are required. |
| LRCLIB | Plain and timed lyric candidates | Planned | Static and synchronized lyric roles are modeled with distinct provenance requirements. | Profile-only; rights, line breaks, timing provenance, cache, and approval gates remain. |
| Musixmatch | Licensed lyric candidates | Compatibility validation | A profile preserves the possible role without claiming availability. | Commercial licensing and authorization must be resolved before enablement. |
| Plex Media Server | Read-only server, playlist, metadata, and artwork context | Available now | Browser-authorized Plex discovery and playlist inspection support a read-oriented application workflow. | Connected does not mean writeback; server and underlying-file mutation remain separately gated. |
| Jellyfin | Planned local-server library, playlist, and artwork context | Planned | A profile and dry-run connector boundary describe planned integration. | No connector execution, playlist mutation, or credential exposure is enabled. |
| Emby | Planned local-server library, playlist, and artwork context | Planned | A dry-run boundary shares the review, identity, authorization, and rollback requirements used for Jellyfin planning. | No connector execution or playlist mutation is enabled. |
| ListenBrainz | Listening-history and enrichment research lead | Compatibility validation | ListenBrainz is being evaluated as a possible source for listening-history and enrichment workflows. | No product profile or live connector is claimed. |
Devices and I/O
Devices, physical media, and live output.
Planning, discovery, routing, transfer, and hardware control are classified separately.
| Device / I/O class | Availability | Supported workflow | What to expect |
|---|---|---|---|
| Secondary or full-screen audience display | Planned | Karaoke Live discovery includes a separate operator view and audience display. | Renderer, display selection, timing formats, and venue behavior still require discovery and validation. |
| HDMI and display-audio paths | Compatibility validation | Display and audio routing through operating-system paths is part of Karaoke Live research. | No universal output, DRM bypass, latency guarantee, or hardware control is claimed. |
| Internal and external audio interfaces | Compatibility validation | PCIe, USB, and other Windows audio interfaces are candidates for device discovery and profile research. | Driver APIs, channel layouts, codecs, latency, and vendor behavior determine feasibility. |
| Optical and coaxial S/PDIF | Compatibility validation | TOSLINK and coaxial digital-audio paths are included in the broader I/O research boundary. | No direct routing, sample-accurate control, or copy-protection behavior is promised. |
| DJ mixers, controllers, and MIDI | Compatibility validation | Equipment interoperability and possible MIDI/control integration are deferred research workstreams. | No native mixer control, synchronization, or ecosystem connector is available. |
| Nearby wireless display and casting | Compatibility validation | Casting is a planned feasibility question for audience display. | Protocol selection, authorization, latency, and content-protection constraints are unresolved. |
| Bluetooth audio devices | Compatibility validation | Bluetooth output belongs to planned device and latency research. | Profiles, codecs, operating-system routing, latency, and hardware support vary. |
| MiniDisc / NetMD preparation | Planned | Order, title, format, capacity, and label preparation can be modeled as a review plan. | Available planning does not include direct device transfer or hardware control. |
| Cassette and DAT planning | Compatibility validation | Cassette side planning is modeled; DAT remains a research-oriented destination. | Recording, transport control, and device operation are not enabled. |
Repair and conversion
Repair and conversion.
Inspection, planning, controlled execution, verification, and recovery are classified separately.
| Repair / conversion capability | Availability | Supported workflow | What to expect |
|---|---|---|---|
| Audio-format recognition and audit routing | Available now | MMW recognizes the evidenced FLAC, MP4/M4A, MP3, raw AAC, Ogg/Vorbis, Opus, WAV, AIFF, WMA, Monkey's Audio, WavPack, and Musepack families for inspection and format-aware review. | Recognition and audit routing do not prove decode, repair, remux, or conversion support for every variant. |
| FLAC structure, tags, and picture-block review | In development | FLAC-oriented evidence covers container and stream identity, Vorbis comments, picture blocks, encoder settings, and compatibility findings. | Inspection remains separate from a repair write or external validation-tool execution. |
| EAC external FLAC command interpretation | In development | The active FLAC profile can parse recognized options, preserve unknown or custom options, and generate a reviewable proposal. | A proposal is not an encoder run or an EAC settings write; backup, approval, verification, and rollback remain mandatory. |
| FLAC verification and decode-integrity tooling | Planned | Planned diagnostics may coordinate trusted external tools for FLAC verification, decode checks, and evidence capture. | Tool discovery does not authorize execution, repair, media mutation, or a claim that damaged samples can be reconstructed. |
| Remux-versus-re-encode decision planning | Planned | A repair plan should distinguish container correction, metadata repair, stream copy or remux, and lossy or lossless re-encoding. | No universal repair recipe is available; codec, container, tag, and player constraints must be verified per case. |
| Broad destination conversion profiles | Planned | Lossless archive and portable-playback profiles are intended to carry codec, quality, gapless, metadata, artwork, naming, and destination rules. | Conversion support is profile-based and expands only after codec and destination validation. |
| LAME MP3, Opus, Ogg Vorbis, WavPack, AAC/qaac, ALAC, and custom external encoders | Planned | The application architecture records these encoder profile families for planned structured configuration. | Only FLAC has active command interpretation evidence; non-FLAC commands are not generated, written, or executed. |
| Quarantine, backup, and source preservation | Planned | Repair and conversion outputs should be staged away from source masters with prior-state evidence and explicit destination identity. | Quarantine and repair-write execution remains planned behind backup, authorization, and verification gates. |
| Checksums and post-operation verification | Planned | A completed workflow should compare intended and observed output, retain checksums, and record verification results. | Successful process exit alone is not treated as proof of media integrity or metadata correctness. |
| Lossy-quality and missing-sample limits | Available now | Conversion may improve compatibility or reduce size, but it cannot restore information already discarded by a lossy source. | MMW never promises reconstruction of missing samples or recovery of original lossless quality from lossy media. |