Open brendan-pike opened 7 years ago
Rather than start a new feature request I thought I'd leave this here.. I'd love to be able to search and filter extensively on existing meta and file data. includes / excludes and special searches, a few random examples;
I've also been aware of the loudness war - once I added kind of support for it: DR is written in O!MPD DB for every track and album, provided that it is stored in tags (dynamic range
, album dynamic range
respectively - I added this tags to all my tracks at once using DR Meter plugin for foobar2000). You can even display DR for currently playing track: in file playlist.php
uncomment line 872:
if (data.dr) params = params + ' • DR=' + data.dr;
In my opinion all data should be taken from tags and user should update data on his own - O!MPD should only have read access to music dir. Also, if it's possible, any external programs should be avoided.
As for second post: this is somehow possible now - you can use quick search. But I think you mean something like query builder for all possible tags or at least indexed ones (O!MPD doesn't index all tags from files, e.g. performer
, engineer
, label
are not indexed, so searching for this values it not possible now). Maybe something like Search page in phpMyAdmin. This could be interesting, but very time-consuming in building.
Hi Artur, I didn't seem to get notifications on the replies thus my slow response.
On your DR points; I can see understand your perspectives. I can probably tack together some bash scripting to insert DR tag myself, I don't consider myself all the tech. savy but I feel this would rule out most users. Having said that I still love that you've taken it into account on some levels.
On my second points, you're right in that I'm describing more of a query builder / advanced filtering. I appreciate it represents a lot of work, maybe we can crowd-found it :-) or at least generate some serious pizza money for you. But highly filtering is what's missing in most free systems, tying my two points together just storing the DR levels is of little benefit if I can't request to be shown tracks with DRs between x and y.
edit: been working on this further, the tool of choice for linux users in fact nearly the only choice is dr14tmeter by default it writes a clean log into the album directory called dr14.txt which is also compatible for import into the http://dr.loudness-war.info database. If OPMP could support pulling this data in automatically if that file exists it will make it very easy for non-tech users although may cross your line of not wanting to touch the music file itself if OMPD wrote that into files meta. Anyway, food for thought. dr14.txt I've attached an example output of " dr14_tmeter -b -d $album"
Hi Artur, I've updated my script to now write the track and album DR to each track. I updated the database and uncommitted line 877 of playlist.php but I'm not seeing the DR shown anywhere?
Hi Brendan,
first of all please check if DR values are indeed written to DB: they should be in table track
column dr
and in table album
column album_dr
. If it's ok, then you should see track's DR in Now playing
:
I have got a general question regarding MPD and dynamic range / ReplayGain. I have read that it's rather poorly supported by MPD beacause of the tags it's looking for. What is your experience with that?
Hi, sorry for late answer - I've missed your comment somehow.
I add ReplayGain to all my albums - I use foobar2000's Scan per-file track gain. It is recognised by mpd and works good, i.e. volume levels are adjusted for all songs. In O!MPD it can be switched on in Now Playing by setting gain to album/auto/track - any of these values applies per-file ReplyGain. I didn't try to add album ReplyGain, so I don't know how (if at all) it works.
Well @ArturSierzant seems like I also missed your answer :)
I have been trying to experiment a bit with ReplayGain. Found out it's working fine with values calculated by https://github.com/Moonbase59/loudgain with are compliant with EBU R128. Downside is that O!MPD doesn't show the DR information for that values, because the dynamic range tag isn't set.
Since I want my DAC to do the MQA decoding mpd needs to run bit-perfect and no ReplayGain can be applied. Hence I was thinking if it would be possible to implement a logic that disables ReplayGain when an MQA file being played.
I've been long aware of the loudness war but after reading this article I was reminded how critical good dynamic range is and found myself wishing I could filter my own collection on DR.
I'd like to suggest that a DR test is performed when indexing (or later via cron). This shouldn't be too difficult to incorporate an existing CLI tool like DR14 T.meter.