beets
beets copied to clipboard
beetbox
replaygain: metaflac backend
I'd like to use metaflac as a backend for the replaygain plugin. On my NAS, neither PAL nor Gstreamer are feasible, but metaflac is available through ipkg.
Sounds reasonable! Now that the plugin is architected to have extensible backends, this shouldn't be a huge implementation effort (in case anyone's looking for a project).
I've started looking into this, but already hit a roadblock. metaflac modifies the source files, and does not have a method where we can have it perform the analysis only. So we could either: A) rewrite the plugin to perform the analysis on the final files, or, B) make copies of the source and analyze those.
A is more work, and B makes for a slower import process. Any other ideas?
That's sad. Maybe we can convince the developers to add a report-only mode?
Barring that, we'd have to do B. (We'll want to support situations where there is no available copy of the file that is allowed to be modified.)
Maybe a PR against https://github.com/xiph/flac? Looks like the official repo is at https://git.xiph.org/, but the repo owners here on GH are the same ones.
Yeah, I'll try that. Sourceforge is being quite prickly and 403'ing any attempts to recover a password.
The --scan-replay-gain code is now in upstream head (https://github.com/xiph/flac/commit/f7c52c8aa8e2a4ccfd98e3ba8d6dbfa04d75a17b) (Thanks mathstuf!)
Should I wait until there's a flac version bump before modifying the plugin to use it? I would guess it's gonna take a while for the change to make it downstream to all distros, etc.
I've personally switched to the bs1770 backend, so I won't be using metaflac after all, but, if it helps someone else...
That's awesome! Great work!
I think the best tactic would be to update the plugin now (or whenever), but fail gracefully if the flag isn't available. That way, we'll be ready whenever the feature trickles down to people's machines.
any info on this, I can see that skapazzo implemented most of the work for FLAC?
