-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Album merging/completion #112
Comments
Since both albums and items have an itime field, I'm putting itime into ALBUM_KEYS_ITEM. This simplifies a lot of handling code. It also will make the item and album itimes synchronize at some points, which is probably fine -- I can't see a major use case for maintaining separate added dates for an album and its tracks.
+1 |
This feature could be included as an option in the "duplicate album" prompt, alongside "Skip New","Keep Both" and "Remove Old" - a new option called "Merge". The merge can be done by setting the @sampsyo are there any obvious problems with this approach? If not I can start making this...:exclamation: |
Yes, this sounds exactly right! Good plan, @udiboy1209. ✨ Just to be clear: the combined album should probably be re-tagged as a unit. That will (hopefully) resolve all the problems with conflicting information using the autotagger. The "as tracks" and "as albums" options show how this sort of thing can be done by creating a temporary pipeline. |
This seems more complicated than I thought. Maybe because I am new to beets' internals. Re-tagging the whole album altogether again is a good idea! But what would you do if autotagging is disabled? |
Yep, it is a bit of a large project... let me know if you have questions about the architecture. Fortunately, in non-autotagged mode, we don't do duplicate detection either, so this will never come up. |
Sorry to be replying after such a long time! I was busy with something else! So I have a few questions. I added two functions to
and the other is The question is that is is safe to put this function will be called from a |
Awesome! This definitely looks like the right direction. Your suspicion was correct, though: we need to avoid doing the remove() call in this stage (presumably this is called as soon as the user decides to merge, right?). The goal is to have all the database manipulation stuff performed atomically in the apply_changes stage. This way, if something goes wrong, we don't end up with a database containing zero of the parts of the albums: it should only be possible to end up in the "before" or "after" state, not in the middle. As a template, you can see that the call to task.add() here: Thanks again for looking into this, @udiboy1209! |
Hmm.. Letting |
Yeah, hopefully we can reuse this existing functionality! Fortunately, the library takes care of cleaning up "empty" albums when the last constituent item is removed. Here: https://github.com/sampsyo/beets/blob/master/beets/library.py#L464 So this should mostly happen automatically. The only exception I can think of is this edge case:
I think this case is edge-y enough to ignore. In any case, it is probably a good idea to leave A in the library to prevent unintentional data loss! |
awesome software guys...greatly looking forward to this merge feature! |
I run into this quite a bit! It would also cool if the duplicates plugin offered a merge option as well. |
+1 to this enhancement for beets I have made quite a few mistakes using the ('Skip new', 'Keep both', 'Remove old') options at import time with mixed up albums and some files already in my library. It hasn't always been clear to me what is the best option to choose - perhaps just my stupidity or perhaps something other beets users have also found. In addition, I think I have deleted some files by mistake when doing import / clean up of existing files using "beet import -L" when using the 'Remove old' option. I would like to see a new 'Details' option added. I think this could sit alongside the merge functions being described above? So the options would now be ('Skip new', 'Keep both', 'Remove old', 'Details') Skip will
and so on for 'Keep Both', 'Remove Old', The user query would then be repeated at the end but would this time have a 'More Details' option which would give the user the option of repeating the above schema but this time with each individual /path/track listed. Sorry if that seems overkill but would be good for import and clean up of some fragmented albums that i have following recovery of part of a hard disk. |
👍 In the meantime, is there any work around to allow us to import a song to an existing album? |
You can always remove and re-import! |
Cool, Thanks. |
This feature would be awesome. Hope it ends up in beets at some point. |
+1000. I think this is absolutely needed for the |
Just came across this issue. This is addressed in 3be5936, at the duplicates plugin level (so, not within the importer). Might still be of use, though. |
From what I'm reading I can imagine the `edit' plugin might come in handy in the process of (optionally?) applying some final tidying edits after the merge (if chosen) since this might have undesired consequences as far as the consistency of tags is concerned. If that sounds useful to you guys it should probably become a new issue, but for now it's only a thought. |
Any news on this? I'ld like to see this feature on beets. This is a must-have kinda feature I think. Currently if I have even 1 track beets skip it saying I already have the album. So maybe adding an Import Missing tracks feature would be wise as well. |
If you're interested in a feature, please consider helping implement it! |
Also, with regard to @nomadturk's comment: Let's say that an album is supposed to have 6 tracks. First, it has to merge the tracks that only exist in one or the other sets, so 1, 3, 4, and 6, I DEFINITELY want to keep. After that, though, I'd want to compare 5. Are they different bit rates? Is one a better musicbrainz match? Different lengths? So I'd want merge resolution to be two stage: union the album as a whole, and then deal with duplicate tracks individually. |
The way this would work according to the current proposal is to reuse the existing importer logic. That means both sets of tracks would get thrown together into one big basket, and that would then be re-tagged as the same album. If you have duplicate tracks, then the "best" one will be picked according to match similarity. Interactively resolving track duplicates would be the purview of something like #154. |
Personally, I'd rather NOT automate the "best" pick... And edit, a la #154 is not the goal...being able to make a track-by-track-non edit comparison and choose one, the other, or both is preferable. |
Right. I'm just saying that manually choosing resolutions like this is actually orthogonal: it can come up in ordinary imports too if you happen to have too many tracks in a folder. We actually have the "edit option" for editing metadata. (See the |
Gotcha, ok. |
Hi, has any progess been made on this feature? I would be willing to help/implement it, but i dont want to do duplicate work or step on any toes. Thanks in advance |
I had tried a few things, but none were particularly useful. Also it was three years ago and the codebase may have changed a lot since then... So you start afresh for this feature. |
Incredible! Looks like I can get back to using beets (something I'm very glad to be able to). |
I'm wondering: how about release groups? They also appear in MusicBrainz and group albums that are basically reissues of one another (stuff like Harmonia Mundi Gold). Could it be possible to extend what has just been implemented with releases to release groups? In many cases you do not want to have a duplicate of the music just because one is the original version of 1987 and the other one is the reissue of 2010 because now it is a legendary recording or because one wants to make money again with it (I'm throwing numbers at random, but there are countless examples). Some people might prefer to keep them separate for the sake of completeness, but I believe this is a minority. So far what I did was to use |
And thanks for the awesome work! |
With “merge all”, it appears that if you attempt to import a song that is already in the album you are merging, beets will rename the song to a totally different song randomly and incorrectly. You will think you have a song when in fact it is a duplicate of another song. For example: Step 1: Import Track 01 and 02 of Album A (which has 5 songs total). Beets imports the two songs into one album correctly. |
Indeed; the current feature combines the tracks; it does not try to deduplicate them. |
Is this issue really closed? I still don't see a way to merge albums in to a single directory.
Is there a command to merge these all in to the same album? |
@laker-93 You can try reimporting by passing the paths to the files to the import command, then select the same album each time and select the appropriate merge option. merge has to be enabled in the config of course https://beets.readthedocs.io/en/latest/reference/config.html#id112 might also be useful: https://beets.readthedocs.io/en/latest/reference/config.html#id113 I think your particular case can be solved but situations with duplicates still can't be solved with the current implementation. Eg: #112 (comment) Is there no issue open for it yet? We could create one out of the referenced post. |
@JOJ0 - thanks for the information. I think that would indeed work for my use case. Another thought is that this could be solvable as a one liner using the |
What I'm trying to achieve here is to import the tracks piecemeal and end up with all tracks being placed in a common directory: An alternative perhaps simpler solution is to set the album id of all tracks to the same with something like:
however doing so would then change the path of all tracks to:
which is still not ideal! |
I've just removed the |
This issue was automatically migrated from Google Code.
Original author: zent...@gmail.com (April 29, 2012 18:26:17)
Original issue: google-code-export/beets#380
The text was updated successfully, but these errors were encountered: