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
2025-01-25 02501, 2025
outsidecontext[m
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?
2025-01-25 02504, 2025
iconoclasthero[m
what's the irc channel?
2025-01-25 02532, 2025
iconoclasthero joined the channel
2025-01-25 02543, 2025
iconoclasthero
this?
2025-01-25 02504, 2025
iconoclasthero
" - 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.
2025-01-25 02524, 2025
iconoclasthero
it says it runs on ALL files in the clustered pane, i.e., the clustered ones and the unclustered ones.
2025-01-25 02552, 2025
iconoclasthero
either way, i'm fairly sure i tried it both ways & it didn't work, but let me try again.
2025-01-25 02526, 2025
iconoclasthero
also @outsidecontext, i need some coffee
2025-01-25 02516, 2025
iconoclasthero
`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.
2025-01-25 02525, 2025
iconoclasthero
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.
2025-01-25 02558, 2025
iconoclasthero
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.
2025-01-25 02518, 2025
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
2025-01-25 02513, 2025
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.
2025-01-25 02534, 2025
iconoclasthero
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.'
2025-01-25 02548, 2025
iconoclasthero
then we don;t have this conversation again! <g>
2025-01-25 02552, 2025
outsidecontext[m
No, scan is always file by file, using primarily audio fingerprint for lookup and using metadata only for deciding between multiple matches
2025-01-25 02508, 2025
outsidecontext[m
Makes sense
2025-01-25 02515, 2025
iconoclasthero
cool, thanks
2025-01-25 02540, 2025
iconoclasthero
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
2025-01-25 02526, 2025
Protopia[m] joined the channel
2025-01-25 02527, 2025
Protopia[m]
iconoclasthero (IRC): The excellent picard documentation website has specific recommendations on workflow https://picard-docs.musicbrainz.org/en/workflows/… 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.
2025-01-25 02530, 2025
Protopia[m]
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.
2025-01-25 02559, 2025
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.
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/
2025-01-25 02501, 2025
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
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
2025-01-25 02559, 2025
iconoclasthero
Blues" album.
2025-01-25 02543, 2025
iconoclasthero
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?
2025-01-25 02552, 2025
lazybookwyrm[m] joined the channel
2025-01-25 02553, 2025
lazybookwyrm[m]
Might just need the CD TOC
2025-01-25 02547, 2025
lazybookwyrm[m]
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
