#musicbrainz-picard-development

/

      • outsidecontext[m joined the channel
      • outsidecontext[m
        iconoclasthero: the SCAN command runs on the unclustered files. If you want to run scan on all the files anyway just don't do the `-e cluster` before
      • thuna` (IRC): not sure what you mean with "the only way to do stuff while returning the empty string". Can you give a specific example on what you want to achieve?
      • iconoclasthero[m
        what's the irc channel?
      • iconoclasthero joined the channel
      • iconoclasthero
        this?
      • " - SCAN Scan all files in the cluster pane." implied to me that it ran on *clustered* files, though that is not what it says, nor is it what you said.
      • it says it runs on ALL files in the clustered pane, i.e., the clustered ones and the unclustered ones.
      • either way, i'm fairly sure i tried it both ways & it didn't work, but let me try again.
      • also @outsidecontext, i need some coffee
      • `picard -e scan -- .` did scan the files, though they went to the wrong album. apparently some of the tracks on Son House "Delta Blues" is on a Library of Congress recording.
      • I would rather that it did what the -e help says which is to scan files in the cluster pane without qualification, i.e. clustered and unclustered ones.
      • what purpose does it serve to only scan unclustered ones? either way, the -e help doesn't match the actual functionality as I read it.
      • outsidecontext[m
        Running on the unclustered ones is also the default in the UI if you haven't selected one. Also clustering before scan doesn't have any purpose
      • iconoclasthero
        ok, so it doesn't *feel* like "clustering before scan [in the UI] doesn't have any purpose", though I'm a human and recognizing nonexistant patterns is one of our innate biases.
      • so if that's the functionality and it's going to stay that way, i propose changing the -e help to ' - SCAN Scan all *unclustered* files in the cluster pane.'
      • then we don;t have this conversation again! <g>
      • outsidecontext[m
        No, scan is always file by file, using primarily audio fingerprint for lookup and using metadata only for deciding between multiple matches
      • Makes sense
      • iconoclasthero
        cool, thanks
      • though, i really don't see the harm in it scanning the clustered ones, in terms of my ripping script, there will always be exactly one cluster anyway
      • Protopia[m] joined the channel
      • Protopia[m]
        iconoclasthero (IRC): The excellent picard documentation website has specific recommendations on workflow https://picard-docs.musicbrainz.org/en/workflow... and these recommend using Cluster and Lookup rather than Scan. IMO Scan should be the workflow of last resort not the default workflow for exactly the reasons you are describing.
      • Picard is first and foremost intended to be a GUI interactive tool, and the command line abilities were added on later and are a reflection of that.
      • iconoclasthero
        @Protopia[m] thanks, I'll look at that, but as I understand it, lookup doesn't work on newly ripped files in my ripping script.
      • i hope this is public
      • but what we're really concerend about is `picard . -e cluster -e scan clustered -e LOOKUP_CD "$dev" 2>/dev/null &` and what i should do to make this work and i think i have enough info now to fix this line when i have a chance/
      • Protopia[m]
        Matching any files to tracks on an album can only be a best guess. Clustering i.e. looking at all tracks as a group is the best way of matching tracks to releases. Without understanding the specifics of your current script (and whilst I can read it I have no idea what the individual tools are or do), my advice would be to find a tool which can get the unique ID of the CD that Musicbrainz stores, and then use this
      • unique ID to the ripped files to a release.
      • You can do this from the CLI with -e LOOKUP_CD
      • iconoclasthero
        whipper's the only linux tool on that list so i'll have to take a look at it. i feel like the info from outsidecontext was what i needed to adjust this so that it pulls in the cd data from the drive before it's ejected and then scan for me automatically. the rest ic an do in the gui as needed. this son house disc is just odd in that the LoC release has matching fingerprints to the actual "Delta
      • Blues" album.
      • out of curiousity, is there a spec on the minimal requirements for a log if I decide i don't want to use whipper but still wish to use log matching?
      • lazybookwyrm[m] joined the channel
      • lazybookwyrm[m]
        Might just need the CD TOC
      • that's what you need to get discids but I haven't messed with that in Picard so idk if it expects the TOC in a certain format or if any file with a TOC in it would work
      • iconoclasthero has quit
      • iconoclasthero joined the channel
      • iconoclasthero has quit
      • iconoclasthero joined the channel
      • iconoclasthero has quit
      • iconoclasthero joined the channel
      • iconoclasthero has quit
      • iconoclasthero joined the channel