Hmm, maybe I don’t quite understand—if you already have MBIDs in those files, beets should use them when you import them as singletons. Does it not? If not, that’s a bug we should try to reproduce.
> On Aug 8, 2016, at 12:12 PM, [email protected] wrote: > > OK so that's sounding like this is really not supported as a top-level task. > > It seems quite simple: > > 1. figure out the correct artist / album for mp3 file by searching > musicbrainz, discogs, etc. (beets does this) > > 2. tag the mp3 file with that artist / album that musicbrainz lists for the > track, erasing anything currently there (beets will not do this unless I > manually edit each by hand and re-type the name that it already has right > there) > > 3. place in the correct directory > > Basically beets won't allow me to do this without manually editing the id3 > tags, even though beets has already made me go through every track > individually and look up the musicbrainz id for each. It's literally > throwing away the information it's already found and which I want to keep. > I'm a programmer so there's no reason for me to edit things individually when > the data is there to automate it. > > Which means I'm back to, "hey why don't I write a script to hit musicbrainz > for all my mp3s and force them to be cataloged correctly" . I'm looking > into the beets plugin process as well but that seems like I really have to > code to the internals of Beets (like maybe flipping is_album=True in > SingletonimportTask, not sure) - not really sure that's worth it here. > > > > > > , and if I'm going to get into manual id3 tag editing, Ithen I'd just write a > script myself to hit the musicbrainz API and write the data. It refuses to > ignore or erase the incorrect album / artist. > > On Monday, August 8, 2016 at 9:25:59 AM UTC-4, Adrian Sampson wrote: > Yeah, the `edit` plugin would work, and so would the more CLI-oriented `beet > modify album=foo`. > > You could also import the with the flags `-ts`, which would turn on timid > mode—i.e., avoid trusting the current metadata—and then you can enter a > manual album and artist for the search. > > One final option would be to turn on acoustic fingerprinting with the > `chroma` plugin, which could do a reasonable job at guessing the original > metadata. > > Adrian > > >> On Aug 8, 2016, at 12:11 AM, cla...@ <>zzzcomputing.com >> <http://zzzcomputing.com/> wrote: >> >> Ok well I'm basically looking to "de-mixtape" these tracks. That is, just >> make them as though I just have a handful of songs that need to be grouped >> into partial albums that they came from originally. So I don't need to >> group them on that "mixtape" id at all. >> >> I'm guessing that if I totally scrubbed these of the fake artist and album >> name, then just imported them as though they were just mixed up, then it >> would do it? Of course another issue is that half the songs on this >> particular "mixtape" as well as a bunch of others aren't in the musicbrainz >> or discogs database at all but I'll try to deal with that separately. >> Would I try to use "beet edit" or something to scrub them out totally? the >> "scrub" plugin didn't seem to really do the right thing on the first try but >> hard to tell where beets cares about the directory structure vs. the id3 >> tags. >> >> thanks for the quick response. >> >> On Sunday, August 7, 2016 at 6:55:56 PM UTC-4, Adrian Sampson wrote: >> Yeah, that’s a tricky case. When we originally introduced singletons, many >> years ago now, the idea was for exactly this case—when you have mixtapes >> from friends with an assortment of unrelated songs. >> >> Really, the “beets way” would be to leave them as singletons and add an >> extra flexible attribute that links them together. For example, `beet modify >> mixtape=cruise2006` or something could mark all the members of a mixtape. >> Then, you’d use a path rule to group mixtapes together in their own >> directories. >> >> The only trouble, of course, is that this approach doesn’t preserve order. >> (Beets needs a “playlists” concept.) But you could consider using the track >> field, or even another flexible attribute, to define the order. >> >> I hope that helps. Good luck, and please ask more questions! >> >> Adrian >> >> >>> On Aug 7, 2016, at 6:45 PM, cla...@ <>zzzcomputing.com >>> <http://zzzcomputing.com/> wrote: >>> >>> Hi there - >>> >>> I have what I would think is one of the primary use cases for beets however >>> it seems to be unsupported. >>> >>> Basically I have a bunch of tracks, all underneath a particular artist and >>> album name, where that artist/album is completely made up. But also, each >>> track with this album is in reality from *totally different albums*. >>> >>> The use case here is exactly what would happen in what I would think is the >>> common use case of someone has a "mix tape" where every song has been >>> tagged with someone's fake "album" name. We want to move the tracks all >>> underneath the actual artist/album they'd be from, given that we are >>> generating only "partial" albums that have just a few tracks. >>> >>> Options I'm working with to deal with this include the "scrub" plugin as >>> well as the "group_album" option. They are still not removing the fake >>> album name even though a *real* album name is right in the musicbrainz >>> listing. >>> >>> Here is a small part of the example I'm working with, this is traditional >>> Indian music (from my wife's collection, I don't know anything about this >>> kind of music): >>> >>> /Aarti/Vaishnodevi/01 01HEY GOVIND HEY GOPAL- NANAK.mp3 >>> /Aarti/Vaishnodevi/02 02 HARI TUM HARO JAN KI PEER.mp3 >>> /Aarti/Vaishnodevi/04 04 DEENAN DUKH HARAN DEV-SURD.mp3 >>> >>> >>> When I do "import" for these, beets can't find anything about an album >>> "Aarti - Vaishnodevi" because there is no such thing. So my only choice is >>> to press T for "as tracks". Whether or not I do "group albums" first does >>> not affect the result. Then it looks up each song individually, and >>> slowly enough I can find close enough identifiers: >>> >>> http://musicbrainz.org/recording/6f80178a-9fb4-4e5e-8901-59c7fe9563cf >>> <http://musicbrainz.org/recording/6f80178a-9fb4-4e5e-8901-59c7fe9563cf> >>> http://musicbrainz.org/recording/e2f04a67-d8fd-4fea-818e-feb62445c453 >>> <http://musicbrainz.org/recording/e2f04a67-d8fd-4fea-818e-feb62445c453> >>> http://musicbrainz.org/recording/7ab29996-6032-474a-975d-1fca8f20edab >>> <http://musicbrainz.org/recording/7ab29996-6032-474a-975d-1fca8f20edab> >>> >>> Because I've had no choice but to select "as tracks", these are forced into >>> "singleton" mode, which means, "there's no album", which I don't really >>> understand since of course there's an album for each one. I've changed my >>> "singleton" format to read "$albumartist/$album/$track $title", rather than >>> "No Album". However, it leaves the ficticious album name in place (or if I >>> use "scrub", I get a dash), and does not use the information from the >>> musicbrainz listing, and I get: >>> >>> /Jagjit Singh/Vaishnodevi/01 Hey Gobind Hey Gopal _ Nanak.mp3 >>> /Jagjit Singh/Vaishnodevi/02 Hary Tum Haro Jan Ki Peer.mp3 >>> /Jagjit Singh/Vaishnodevi/04 Deenan Dukh Haran Dev _ Surdas.mp3 >>> >>> this is wrong. Ignoring that musicbrainz' release titles look a little off >>> here, what it should be based on those ids, is: >>> >>> /Jagjit Singh/Hare Krishna: A Live Concert/01 Hey Gobind Hey Gopal _ >>> Nanak.mp3 >>> /Jagjit Singh/Kare Krishna A Live Concert/02 Hary Tum Haro Jan Ki Peer.mp3 >>> /Jagjit Singh/Hare Krishna: A Live Concert/04 Deenan Dukh Haran Dev _ >>> Surdas.mp3 >>> >>> Is there some option for this behavior or is this an unsupported use case ? >>> (what do people organizing old mix tapes with bad album names do? ) >>> >>> >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "beets" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to beets-users...@ <>googlegroups.com <http://googlegroups.com/>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "beets" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "beets" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "beets" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
