More > Media Center 17
Can you have single tracks appear in multiple Albums?
sunfire7:
If 2 or more albums have the same track, most of the time I delete one of the repeated files and I end up with an incomplete album.
I like rick.ca's pseudo-file suggestion to allow albums share one physical file but with different tags.
Example:
Top 10 week 20: Top 10 Week 21
Track1.flac Song1.flac
Track2.flac Track2.flac
Track3.flac Song3.flac
As you see both albums share the same track number 2.
You could create .jrs in MC right clicking Track2.flac and selecting "create shortcut". This would create a new shorcut item with the same tags of the original, and then you can change the tags you want (Maybe album name and cover).
JRiver would keep the shortcut tags in DB and optional in Sidecar .jrs file independently from original flac.
After doing it you would have this (.jrs file would have a much smaller size than original flac)
Top 10 week 20: Top 10 Week 21
Track1.flac Song1.flac
Track2.flac Track2.jrs
Track3.flac Song3.flac
In this case the Track2.jrs file would point to Track2.flac file but will be able to conserve its own tags (maybe album and cover different from .flac). In MC browsing the Top 10 week 21 album would appear complete and the track2 would have some special icon indicating it's a shorcut file, but will act as a normal song.
What do you think?
rick.ca:
--- Quote ---What do you think?
--- End quote ---
Maintaining a "sidecar" to a file that doesn't exist doesn't make sense. And I'm not sure what purpose one about a link to a file serves. It's existence in the file system would be be rather confusing. So I don't think there's any need to represent pseudo files in the file system in any way.
As far as indicating what a pseudo file is linked to, this is consistent with what I've suggested—as far as it goes. What you're calling a "shortcut," however, is just a pseudo file that has been linked to an existing file. There would also be pseudo files not linked to anything. If a pseudo file is linked, there needs to be a way of indicating what it's linked to. Your suggestion is a sensible way to do that, although the file extension of the real file needs to be retained (e.g., Track2.flac.jrs). But it's not a real file anyway, so it could also be something like Linked to (Path)\Track2.flac where the Linked to is not part of the data—and therefore doesn't affect sorting, etc.
There would also need to be a way to distinguish all pseudo files from real files. I'm not sure how important that is. It may be clear enough from [Filename] and unique icons. But in some situations, such as a pseudo album where some but not all tracks are linked to files, a bolder indication of the "file type" is probably warranted. Depending on how that is done, it may not be necessary to even use the JRS extension. The linked file would be displayed in [Filename], and it would be otherwise evident it was a link.
--- Quote ---If 2 or more albums have the same track, most of the time I delete one of the repeated files and I end up with an incomplete album.
--- End quote ---
Just to be clear, I think we agree on what's important—the end result. In this situation, you would right click on the file you want to use (e.g., one identical to that of the subject album, but better quality) and select Create shortcut. That would create a record that's an exact duplicate, but linked rather than directly associated with the file. You would then change [Album] to the value of the other album, and delete the real file in that other album. The task could be done in seconds. And by displaying only duplicate files, performing the task for multiple cases would be easy.
flac.rules:
--- Quote from: jmone on October 29, 2011, 08:32:39 pm ---I'd suggest that playlists are still the go but that any tagging / coverart you do just stays in the DB and is not copied to the files. That way you can have any mix and match, display them anywhere, tag them as you want but it is all just in the DB. The pseudo file concept is just a way around the limitations that we have with the current implemention of the DB. As you know from this thread http://yabb.jriver.com/interact/index.php?topic=66392.0 we can create duplicates in the DB that point to a single item (and it will work with any type including Audio) + we can tag them up individually ....but to your point at present if these tags are ever written back to the file they will trash the old ones (unless you make the file Read Only).
--- End quote ---
I also feel that playlist might be the best and most flexible way to go. However one should have better ability to tag playlists themselfs, not just the files (like giving a playlist 3 stars)
Navigation
[0] Message Index
[*] Previous page
Go to full version