#musicbrainz

Now as I move files back and forth doing puid checks, all the dupes end up together, lots of (1), (2), etc. So last pass, load all into Picard, save+move, delete everything left behind (all the dupes).

yllona: nope, just arranger, non specific :(

brianfreud: could you live without it? the patch surely makes duplicate handling easier for most users as they get just displayed in picard

BrianFreud: how do you 'delete everything left behind'?

well, I know I'm not the only one using it for dupe checking. I don't mind it, but it's not a bug (like the last dupe checker removed from Picard), it's a functionality change. Hence why I suggested a checkbox option.

luks: save+move? If I'm moving with Picard from c:\foo to c:\bar, anything left at the end in c:\foo is the dupes

oh

this is based on the fact that picard doesn't not save/move 'unmatched files'

yes

but the soon-to-be-released 0.10 does save/move them

oh?

there was a ticket by fauxfaux

lol, the last time you changed that behavior, I have to stop using the old method and switch to this...

(based on how you'd changed the unmatched files behavior)... guess .10 breaks that

I did change that before?

yes

I think I was the only one who ever noticed it on the last one though

hm, maybe it really _was_ in 0.9

but I don't understand how this 'dupe finder' can work in 0.9 then

yes, that was the one

oh oh

it doesn't. That was pre-beta... 12? 14?

the ticket was to NOT save them

Back then, it moved them, but separated them into a new subtree which was safe to delete.

As unmatched files works now, it doesn't move them at all, but they still end up segmented, old dir vs new dir, still easy to delete en mass

still, how do you decide which one to keep and which one to delete

they might have different bitrates, or even different formats

Given that both are the same original, the only difference is in when Picard tagged them.

and picard assigns them more or less randomly

At least on Windows, when Picard is running the puid routines on a file, it locks the file. It does not always release that lock, however. As part of puid submission runs, I save twice.

why there isn't a bug report about that? :(

Figured it was an OS/QT issue, not Picard.

Qt has nothing to do with files

it might be a bug in ffmpeg, but it's still picard's responsibility to clean the locks up

Load files. Move all to left. Scan files. Save files to \processed . Submit. Move all back to left. Rescan files, all with (now) puid-matches move to the right. Clear all those remaining on the left, fix any that loaded a new release (1 file:2 puid matches, etc), resave the remaining on the left to \puid-done

unmatched files get saved only if selected directly, not if you save the album. but otherwise the behavior seems to be the same for 0.9 and soon to be 0.10

outsidecontext: yeah, I was confused by that pre-0.9 ticket

Somewhere in that process I end up with dupes. So once I've run \original and \processing through the mixer enough that both are finally left empty at the end of all this, rerun \puid-done through Picard, and save to \done. Now everything left in \puid-done is dupes.

no wonder it takes you so long to get your library tagged :)

but because metadata (at MB) gets updated, puids get embedded, etc, the dupes are not bitwise identical, so standard dupe utils don't catch them, too much variation between the tags.

brianfreud: the goal of all this is to submit puids to MB, right?

yes

luks: nah, the scans I run while I sleep - the rest takes only minutes. (Except saving itself, which is dog slow...only about 10/minute)

outsidecontext: problem is, I want to segment those that have puids from those that don't

awfully complicated and surely error prone process :)

those which don't get matches from mip need another run through the mixer, or have something funky in their tags which needs to be fixed so the mixer and picard can gen and get puids

BrianFreud: no, I mean all the passes, etc.

just tag your files and be done with it :)

lol

well, in the process, I do benefit too - I catch those files with doubled tags, broken tags, broken initial vbr frames, etc

i prefer having some button for calculating the PUIDs for all my collection, submit it and notify me if some files need a second pass

outsidecontext: I have a prototype of a standalone c++ app for that. never finished it, obviously

how do i get the "please vote for box" to go awy? it's getting the way

but I have, hmm, maybe 300 dvd's worth of post- \done files backed up now, so it works, even if slow

luks: i have a prototype of a python app inside of picard, not finished yet, though

yay for non-finished software :)

:) yeah, it's the best

luks, just curious... what happened to picard 0.8?

I reserved that for possible wx-based picard update

(if picardqt would fail)

ah

but then yeah, if you weren't aware of it, I can file a ticket on the lock not releasing.

It does release when picard closes or crashes, but not always post-analysis

hello warp

hello :)

just got your email

you're fast :)

that script would be useful for testing.... and would allow me to focus on other things(at least to start with)

hehe

but Im not sure if this is okay

niklas: why not?

good question :)

wanna confirm with some mentor

niklas: re-using existing stuff is efficient, and generally a Good Thing. i'm sure there is enough work in the other bits, and especially if you just use my stuff for testing, there should be no trouble at all.

true

stealing source code is what "Open Source" is based on...

anyways even if I for some reason have to write the tool myself I can focus on the server side at first, using your tool for testing

and then write a tool myself if required

yeah, I'd tend to think OS style code-reuse would be encouraged, not forbidden, if it gets the work done better&faster

if this is not too much trouble for you

niklas: if you could write up some kind of API document, i'll clean up my code a bit and implement that. i expect i can have something useful in an evening of hacking.

sure will. thank you.

it's in python btw, but you probably guessed that already. it'll still be useful for testing :)

I figured :)

moose.

Downloadable for free but with compulsory email registration: Accept or Reject? http://musicbrainz.org/show/edit/?editid=8700708

reject. imo. other people disagree iirc.

why reject? the NIN release also requires you to provide a mail, and I believe it's linked in MB

luks: i disagree with that one either then, obviously.

outsidecontext: Given that 2 of the 3 were "pre-nominated" 4 days ago, I don't see anything objectionable in 3 at once.

maybe I'm the only one, but i can't quite keep up with 3 at a time every few days

well, it's only been one every 2 to 3 days, excluding the original group, this is the only time it's been 3 at a time since then

luks: the NIN torrents of ghosts does not require email addresses, dunno about the slip

brianfreud: yeah, i just think it wouldn't hurt to only nominate one at a time. we have no hurry

one at a time for the full week?

gioele: the slip needs an email registration for download

Given that almost everyone who is voting at all normally votes in the first 24 hours, I don't see the need.

brianfreud: just not 3 at a time

BrianFreud: i haven't checked nor voted on any of the recent nominations, don't have the time. i prefered the old nomination frequency really.

BrianFreud: I agree with outsidecontext. One at a time is more than enough

sorry, I just don't see the need to limit it to one a week.

actually one a month would be better for me

nor was that what we discussed a month ago on the list.

BrianFreud: it takes a lot of effort and time to do an editor review

I understand.

BrianFreud: i don't object to the higher frequency, i'm only stating that as a result, i will not be participating.

i won't vote on any editor i can not have a closer look

but I think advance notice of intent to nominate 2 names on 5/9, with their actual nomination, plus 1 more person, on 5/13, is sufficient time in which to consider a whole 3 editors.

i don't get it really why you want to rush this though. how many are left on your list?

there were initially 107 iirc

I don't have that drive hooked up at the moment to see how many are left though

k

I'm trying to keep the frequency to an average 2 to 3 days per. In this case, I'd said I wouldn't officially nominate any between fri and mon due to the summit - today's 3 simply were the two mentioned on 5/9, plus the one I had scheduled to nominate today. :)

I don't think this is a good way to nominate autoeditors

well, we've accepted all but 2.

How would you suggest we nominate them?

nominate people you know or vote on their edits

that was the entire point - we've been doing just that, hence we had an autoeditor pool that was reflective of that.

I just don't like doing it based on the number of accepted edits

If you can think of a better way to find them, sure.

who says there was something wrong with the old way?

(exept you, obviously :))

But we had a lot of autoeditors in certain areas - musically and geographically, with many areas totally unrepresented, so no autoeditors working there.

if you can't find them, then there probably aren't any

if makes no sense to nominate people nobody ever notice

*it

well, looking at pbryan, kurros, montesquieu, knakker, acid2, Muzz, PhantomOTO, chopinhauer, Shlublu, alphaseven, adan_aileron, t0n3t, chiark, and jongetje, I respectfully disagree.

My eeeears are burning!

So are mine!

I see it as the usual 'looking for a problem where there isn't one', but that's just me

agreed

feel free to think that.