Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bennyd]

Small question:

I have mp3's which in fact belong to multiple albums.
For example Purple Rain of Prince belongs on the album "Purple Rain" but also on "The Best Of Prince" and maybe on some other compilation albums.

How do you solve this in MC ?

- Do you just tag this into 1 album in the album field ?
- Do you create a custom multi value field ?
- Do you create seperate playlists for each album ?

If I synchronise the music to my HTC Hero (android), I want the song to appear in all albums when playing, but the Hero only uses the "album" field for showing albums.

Any suggestion are really appreciated.

[Vincent Kars]

A very simple solution
See to it that each album has its own directory
If you use this model, simply see to it that all the songs are in this folder and give them all the same album name

[bennyd]

A very simple solution
See to it that each album has its own directory
If you use this model, simply see to it that all the songs are in this folder and give them all the same album name

Thanks for the suggestion.

With your suggestion you mean in case of the example above I would need to copy the "Prince - Purple Rain.mp3" track multiple times in different folders for each album ?

If this is what you mean, I will have duplicate files which are in fact the same, so in my library, if I search for "Prince - Purple Rain", I will find it multiple times in stead of 1 time (but listing to which albums it belongs).
I rather not have to duplicate the files on my disc, if I have to re-tag a file with eg. lyrics, I have to check if I don't have duplicates where this needs to happen as well.


Or am I understanding it wrong ?

[Vincent Kars]

You understanding is perfect.
But what is a Album?
In general media players thinks all songs belong to a album if the album title and album artist are the same.
So to moment you alter any of this tags in a song, the album will be incomplete.
But as a I said, it is a simple solution
A probably to complex one would be to make custom tags and do some like Album1, Album2 etc
Than you need a kind of expression like if song is in folderX use Album else if in Folder Y use album1 etc.
But that looks a bit like a disaster scenario to me (and won't work on your Hero)


On OS level this could be easily solved by using symbolic linking but this won’t resolve the tag issue

[bennyd]

Thx Vincent,

I will think about it for a while :-)

[rick.ca]

When I first considered this, it was based on the premise that duplicates were obviously a bad thing. It didn't take me long, however, to come to the same conclusion as Vincent. Tagging a track that's a duplicate of one already tagged seems like a redundant effort, but in the context of tagging the entire new album it doesn't really make any difference. The time it would take to handle it differently (so there would be no duplicate, or at least to get the tag information from the existing file) would likely take longer and be more error-prone. Just accepting duplicates is the easiest way to maintain album integrity. Duplicates showing up in the same playlist doesn't concern me, as they can easily be excluded. I suppose the legitimate concern some would have is that duplicates will make their playing stats less meaningful. This doesn't bother me, as I tend to listen by album anyway.

When I examined the duplicates in my collection, I realized there was a more important issue. Some were of significantly better quality than others. It really did seem pointless to listen to a poor quality recording (I still have some 128k vinyl rips!) when I have good quality version of exactly the same thing. So I carefully determined which ones were, in fact, duplicates (i.e., and not different re-recorded, re-mastered or live versions) and replaced the lower quality files with the higher quality ones.

So, starting with a concern about how to get rid of duplicates, I ended up making sure my duplicates were exact duplicates.

[dcwebman]

Having to require duplicates in order to solve the problem of being on multiple albums has always been brought up. An aliasing solution where you could tag that one file with multiple albums when they are exact is the answer but the response has always been that disk space is cheap. However when you go this route like mentioned, if you change something like the lyrics on one, you better make sure you change them on all copies. Sure would be easier to just have one copy that you need to update.

[ChrisRainman]

This issue came to my mind at least a hundred times and it's good to see that others deal with the same issues. I also thought of having a second album field, maybe list delimited but in the end these solutions don't help in every situation (like with Hero as mentioned above)

I think, it's very important to understand why this topic comes up again and again: Nowadays, nobody ever would ask for a solution for this because of disk space!

In fact, the only reason is the aim of having a well organized library which is consistent. All music collectors having 10-100.000 files in their library get in contact with this issue sooner or later. Tagging a file means always searching for duplicates first, then applying the tags to all the files. And you need to do this tag by tag - if there was a way to copy + paste all tags in one step would already be a great addition. Anyway, the manual work is immense and for large databases no option.

An aliasing solution where you could tag that one file with multiple albums when they are exact is the answer but the response has always been that disk space is cheap.

That would really be the perfect solution and I wonder why this is not considered to be developed by JRiver. This would make MC really unique and make it No1 by far for all people managing larger music libraries!

Would this really be so complicated to provide such an aliasing feature? What would be necessary from a user point of view?

1. Assigning multiple files to one master file which keeps the physical file storage.
2. Playing or burning or exporting or copying an alias file then means include 1 further step - to point to the "master file" and then perform the action.

Maybe, this is too simple from a technical point of view, but why shouldn't we discuss it and ask you to really add innovations which are really unique and valuable?

[bennyd]

Why not use the existing "Stack" function ?

But expanding the stack function then with:

- When changing a tag in one of the stacks, that it asks to update the other stacks as well
- expand the option a bit of hiding/unhiding stacks so it supports multiple albums
- When synching a stack to a portable device, that it checks how many stacked files it has to sync depending on the tag differences (or asks)

[rick.ca]

Would this really be so complicated to provide such an aliasing feature?

Yes.

I'm not sure it would be too complicated, but it's certainly more complicated than you've implied. First, I think we can agree an "alias" would at least serve as sort of a "shortcut" or link to a physical file in a different location, while otherwise behaving (as a library item) like any other file. That would be a nice solution for the issue I commented on—ensuring the collection only contains the best quality version of an otherwise identical track. But you want it to assume the tag values of the source track as well. That's quite a different matter. Not all the tags can be the same. Obviously Album is different. Other than that, it may be safe to assume all the other fields should be the same, but how do you know for sure? Perhaps others should be different as well, based on the context of the album (or whatever the reason for the duplicate). Even if the developers could get away with arbitrarily deciding how that should work, what about custom fields?

Assuming there were a way to automatically clone tags from the original to the duplicate, then what? Should changes to any of the linked records result in the the change being replicated to all linked records? I'm afraid in some cases that's going to be undesirable. For example, the relationship of one duplicate to the original may not be the same as a second duplicate, yet changes to any one would affect all three. Assuming an alias is going to be "transparent" once created, this situation might even be dangerous—if the user is unaware of having created the undesirable result. No, I don't think it would be practical to link tag values. It would be handy to be able to copy or clone tag values from one record to another. Such a feature would be very useful generally, and should not be tied to duplicates (i.e., it might be convenient to clone a similar record, and then edit it).

Tagging a file means always searching for duplicates first, then applying the tags to all the files.

Since I never do this, "always" seems a bit of an overstatement. It may be a sensible approach if adding a multi-artist compilation album that likely contains duplicates. When tagging a single-artist album, however, I'm going to tag the whole album before giving any thought to duplicates. I might then display duplicates and reconcile the minor differences that sometimes occur in track names. As for lyrics, I prefer to do them hundreds at a time—rather than by album—so I'm spending only seconds per track. Getting the lyrics from an existing duplicate—even if it's done automatically—is not going to make much difference.

Playing or burning or exporting or copying an alias file then means include 1 further step - to point to the "master file" and then perform the action.

These "master files" would need special treatment in other respects. Deletion should probably be impossible—until the links are removed. In some cases, copying an alias or a master is going to require clarification as to whether a copy or another alias should be created. And I certainly hope I'd be offered a way to replace a master with a better quality version—without having to jump through even more hoops because of the aliases.