Moonbase: Will do, thank you.
Brian Ritchie:
> I didn't realise at first that you have to define the Media
> Library(-ies) (and not just the playlist folder) before it will really
> look for matches - just thought it wasn't doing a good job!
I do have a popup that warns you about this when the program starts up
with no media directories defined, but I agree that the messaging once
you are in the application could be improved as well.
> More details of matches (e.g. artist, album or just path) would help
> disambiguate - filename alone isn't always enough. (Both Dodgy and
> Leaves have albums with track 06 - Good Enough!)
I added something to address this in version 1.5.3 - not wanting to
increase the size of that screen, I made the path to the match show up
in the tooltip, just hover over the row and it should pop up.
> It was foxed by "11 - Faraway.wma" (and even "11 - Faraway.flac") when
> the new file (in the same folder) was called "11 - Far Away.flac"
This is a problem I haven't quite worked out yet. Scoring is currently
token based so the space makes those two distinct words which are then
compared individually for equality with the tokens in the other
filename. I suppose I could measure the "distance" between the tokens
instead using some metric and base the scoring off that, but I haven't
gone that deep with the analysis yet.
> When I switched playlists without saving, it didn't warn me that my
> changes wouldn't be saved (or ask me to confirm that I wanted to lose
> them)
I recently added a warning like this for closing the application when a
modified playlist is open, so doing the same when switching playlists
will be easy to add in 1.5.4.
> details at bottom ("Number of lost entries" etc.) too pale - hard to
> read, and I didn't realise they were there at first!
Will be easier to read in 1.5.4.
> "12 - You.wma": "12 - You.flac" was on 2nd page of matches; algorithm
> seems to prefer longer versions of short titles, e.g. "You Got It Bad".
In this case if the matches all had the same score you might've been
seeing a side-effect of the fact that sorting among tied scores is by
full path. Hovering over the row for the tooltip should make it clear
if this is what caused what you were seeing.
> I found that sometimes it took a couple of clicks to get the right-mouse
> menu to appear over a selected item. Also, since right-mouse in the
> tracks list is greyed-out when no track is selected, it might be nice
> if instead it also selected the track under the mouse (saves having to
> left-click to select it first)?
This has bothered me for a long time... I had trouble getting
right-click selection working right the last time I tried but I'm a
little better with swing now so maybe I'll give it another shot. We'll
see how it turns out in the next version.
> I haven't tried it, but it's not clear whether a list that's been sorted
> (say to put all Not Found tracks in one place) will then be saved in the
> new order; if so, then it would be good to be able to go back to the
> original playlist order.
This would definitely change the way the list was written out. There
are ways around this though. Do your updates, save a copy, then mess
with the order and you can always revert to the saved copy with the
recent playlists menu (under "File").
> It'd be lovely to be able to select all the tracks in an album that's
> moved, and to have listFix() find and update them all at once; but I
> can imagine that would be a nightmare working that in with the
> approximate string matching! (In one place, I decided it would be
> easier just to drag/drop the new albums into the playlist in an editor
> that supports that (such as foobar2k)). It'd be good to be able to
> apply changes to multiple playlists as well.
If the tracks are named the same as they were before you moved the
album this should be automatic just by pushing the "Locate Files"
button. If you are talking about inexact matches (filenames are
different), then yes this is a little tricky. I'm thinking about an
option that would allow the program to automatically pick what it
considers to be the best match as a replacement in these cases, but
reporting back to the user about that could be tricky and not reporting
could mean you get matches you don't want. It would definitely be a
"use at your own risk" type of feature.
> But that's just being greedy! listFix() already looks like it'll be
> pretty useful. It really has rescued some playlists that I was about to
> abandon, or rebuild from scratch. If only I'd found it yesterday! :-)
I'm glad you found it helpful, now you can reorganize your collection
at will - freeing isn't it?? :)
--
firewyre
------------------------------------------------------------------------
firewyre's Profile: http://forums.slimdevices.com/member.php?userid=29734
View this thread: http://forums.slimdevices.com/showthread.php?t=42597
_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/ripping
