Print

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

[jmone]

Say I want to have the following Albums (compilation of various artists):
- Top 20 Week 1
- Top 20 Week 2
etc

Obviously, many of the tracks are identical from week to week.

I know I could do this with Playlists, but
1) is it possbile to keep all the tracks physically ONCE on the HDD yet have them appear in multiple Albums under (My Fav View for Audio) "Album Artist (auto) / Album" view scheme?
2) Alternatively, can you make a Playlist appear under the "Album Artist (auto) / Album" view scheme?
3) Otherwise I'll just keep multiple copies of all tracks.....(disc is cheap)

[fitbrit]

I've wanted this feature for a while too. Sometimes the exact same track appears on more than one album anyway, and it would be nice to replace the track on an older album with one of higher quality, for example. So that when that track is supposed to play, it's always the highest quality one that gets played, no matter which is the parent album.
I've long wondered whether MC could be developed to use shortcuts, or aliases in Mac parlance.

[rossp]

or links in Solaris parlance.....

[Gl3nn]

I've asked a similar question on the MC 16 board (http://yabb.jriver.com/interact/index.php?topic=67086.0) re: using 'Playlist Groups' in a Library View and not being able to have the Playlists sorted in the order they come.  Otherwise, I think the two "requests" are about the same.

Nobody from J River answered my question.

[jmone]

Interesting, Shortcuts do work (sort of).  Create a shortcut of the track you want, import it into MC, add coverart, and tag it up.  When you play the shortcut, MC will go and play the real file.  Downside of course is all the autogenerated tags are for the *.LNK file not the actual music track (so this is really not a solution).

[Vincent Kars]

Sometime ago I had a more or less the same problem.
You have the original album and ‘the best off’ and they have overlap.
I wanted to have all the tracks in each album but under water 1 physical track on the HD.
So I removed the duplicate from “the best” and made a symbolic link instead.
Technically it works, it plays.
But MC reads the tags so the album is the album title of the original.
I never tried tagging the symbolic link.
I wonder if one does, if this will overwrite the info in the track on the HD as well.

[Sandy B Ridge]

I never tried tagging the symbolic link.
I wonder if one does, if this will overwrite the info in the track on the HD as well.

I guess the way round this would be to not have tags in the audio file and have them in sidecar files. Then you'd have to make the audio files read only. This would force MC to add a sidecar XML to both the original audio file and the symlink which you could then have different data eg Album name and coverart associated with the two 'instances' of the file.

SBR

[Alex B]

This is possible with tailored cue sheets or MPL playlist files. Not easily though. You would need to manually create a new single track cue sheet for each new duplicate track or create mpl playlists that contain similar cue track data.

http://yabb.jriver.com/interact/index.php?topic=29082

Edit: For more than one virtual copy of a track you actually must use the MPL method.

[JustinChase]

This is possible with tailored cue sheets or MPL playlist files. Not easily though. You would need to manually create a new single track cue sheet for each new duplicate track or create mpl playlists that contain similar cue track data.

http://yabb.jriver.com/interact/index.php?topic=29082

Edit: For more than one virtual copy of a track you actually must use the MPL method.

it seems like it would be rather easy if/when MC gets the server split from the customizations.

http://yabb.jriver.com/interact/index.php?topic=67229.msg451697#msg451697

They would likely need some sort of File ID (FID) to link the metadata to the actual physical file/media.  If multiple users could have different views/ratings/names for the same file, they would have to link to the file, not directly access the file.  The profile tells the server it wants FID=12345, and the server knows that refers to a file called The Beatles - Yellow Submarine

This means that the link for me to connect to a song can be put anywhere, including as a track in multiple albums.

When user/profile "Bob" connects to the server, his profile shows that file is called The Beatles - One - 15 - Yellow Submarine - Rock & Roll

When another/profile user connects, they have that same file called The Beatles - Revolver - 16 - Yellow Submarine - Pop

They could ALSO have this track configured as The Beatles - White Album - 1 - Yellow Submarine - Classic Roll

All of them pointing to the same physical file on the library server (FID=12345), which feeds back The Beatles - Yellow Submarine when any of those 3 are selected by anyone.

IF, the physical files ever get split from our metadata about them; someday; maybe

[rick.ca]

We've discussed before the use of dummy files to facilitate library records for which there is no associated media file. It would be helpful if a pseudo file could created directly in MC. A logical extension of such a feature would be the ability to link that pseudo file to a real media file—so it would act as a shortcut.

This would allow the creation of a "pseudo album" for a variety of purposes—where some or all the tracks are linked to real media files. Tempted by the latest compilation release by your favourite artist? If you already have an extensive collection, create a pseudo album from it's track listing and link the tracks you've already own. Or maybe you're buying the compilation because it's tracks are of better quality than those in your original albums. In that case, do the reverse—replace the old tracks with links to the new. And, of course, it would be an easy way to handle jmone's example—creating albums for lists that are not, and never will be, real albums. A linking tool could even display a list of the real files you most likely want to link to.

Crescent's question, usually in a more general form, comes up regularly. Why can't we tag and display playlists in views the same way we can with albums? There are good reasons. A playlist is just a list—the tracks that appear in them are the records of the actual tracks. Changing them would change the albums the tracks come from. But pseudo files would not have this limitation. A very cool companion command would be Create pseudo album from playlist. That would instantly create an album from a playlist (which might be a smartlist created for the purpose), renumber the tracks in list order and set [Album] to the list name.

[jmone]

The answer is already in MC = Playlists.  What we would need is the ability to show Playlists under the main section headings just like other "albums"

[Vincent Kars]

The only thing that pops up as an album and is not a audio file is a CUE sheet.
Never tried but if you add a second file statement maybe it works


TITLE "Top 100 Week 1"
FILE "hit 1.mp3" MP3
TRACK 01 AUDIO
PERFORMER "Artist 1"
TITLE "Hit 1"
INDEX 01 00:00:00

FILE "hit 1.mp3" MP3
TRACK 02 AUDIO
PERFORMER "Artist 2"
TITLE "Hit 2"
INDEX 01 00:00:00

[rick.ca]

The answer is already in MC = Playlists.  What we would need is the ability to show Playlists under the main section headings just like other "albums"

Perhaps they could be made to display in a regular view, but their contents cannot be tagged without changing the original tracks. I understand this may not be necessary or even desired for the application you have in mind, but the solution I suggested has a much broader application. And it would avoid the confusion that would inevitably result from mixing playlist entries with real files (which is likely the reason we can't do this now). Pseudo files could be added, tagged, displayed and deleted exactly like real real files. If there were any compelling reason to display a playlist as an album (and surely it is a special case), one could be created effortlessly with a Create pseudo album from playlist command.

[JustinChase]

Perhaps they could be made to display in a regular view, but their contents cannot be tagged without changing the original tracks. I understand this may not be necessary or even desired for the application you have in mind, but the solution I suggested has a much broader application. And it would avoid the confusion that would inevitably result from mixing playlist entries with real files (which is likely the reason we can't do this now). Pseudo files could be added, tagged, displayed and deleted exactly like real real files. If there were any compelling reason to display a playlist as an album (and surely it is a special case), one could be created effortlessly with a Create pseudo album from playlist command.

'pseudo' files could be treated exactly like 'real' files except the RID would not actually point to anything.  Otherwise the cover art, stats, whatever would behave exactly the same.  If one day you acquired the actual media file, you just tell MC, here is the media for this record, and it stores it away with the rest of the media, no big deal.  Clicking play could force MC to ask you if you have it now "The file is not available, would you like to add it now?"  [Rip]  [Browse]  [Link to another file]

[jmone]

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). 

[rick.ca]

The pseudo file concept is just a way around the limitations that we have with the current implemention of the DB.

I introduced the term "pseudo file" to suggest a useful feature that would address your original need (not to imply you would want to address it that way), other things like it, as well as a wide variety of other applications. The term was intended to have it's dictionary meaning, not establish any "concept" about how the database works. At the same time, there is an implied assumption this is likely something that is feasible. While I don't have the technical background to understand how, I am aware there are other things recorded in the database that are not files. So it seems reasonable to assume the functionality proposed is not beyond the capability of the developers or somehow contrary to the current architecture of the database.

From a user functionality point-of-view, the "pseudo file" I'm talking about and the entries in a playlist are completely different things. Making the distinction between the two is the whole point. Playlists are lists of files. That's what everyone understands them to be, and there's no reason to change that understanding. Pseudo files are database records just like those for files, that can be tagged and displayed like files, but they don't represent actual files. I've suggested they could take on the same function of playlists (i.e., playing) by optionally including links to actual files in the library. There's no advantage to twisting the meaning of "playlist" to accommodate pseudo files. There's value in the separate meaning of each of the two concepts...

but to your point at present if these tags are ever written back to the file they will trash the old ones

...This is just one natural consequence of confusing the two. If you give playlist items the same treatment as pseudo files, then they become pseudo files. That's great if we don't need to distinguish the two, but we do. Otherwise, how do we make a list which is strictly a list? How do we make a playlist of pseudo files? And how do we know if the items we're tagging or deleting are playlist items, pseudo files or real files?

[jmone]

Thanks Rick, got you.  I come from a DB background and the current limitations are purely a JRiver decision on how they want to handle things.  The file (and path) are not the primary key, they are just another value in the DB field that references the file itself.  There is absolutely no technical limitation in a DB to have multiple entries with individual values for the tags that all reference the same file.  Of course they would need to introduce some logic on which ones updated the tags in the file itself.  This concept in MC already exists for cue files, and as we have seem can be forced (but is ugly).  We are also seeing the development of a similar approach of breaking a single BD into multiple eps.  I'd say it is more of a development priority and how many of us care and want such a feature.  

[Gl3nn]

Crescent's question, usually in a more general form, comes up regularly. Why can't we tag and display playlists in views the same way we can with albums? There are good reasons.

I was happily in the dark until I discovered that you can, in fact, select 'Playlist Group' when creating a view.  Why allow that functionality when the result is a complete reordering of any carefully compiled and sequenced playlists?  I still don't get it.  I don't want to 'tag' anything.  I just want it displayed in the order I had it.

[rick.ca]

I'd say it is more of a development priority and how many of us care and want such a feature.

I'm not sure what you mean by this. Are you agreeing with me, or claiming that development is taking a different direction? I'm not sure why you're now referring to the case of needing multiple entries for an individual file. This is just one of many cases that would be addressed by the conceptual framework I'm suggesting. I see it as an issue of how to define the link between what I've been calling a "pseudo file" (in this case, "entry" might be a better word) and a real file. Yes, rather than being a simple 1:1 link, it needs to be able to link to parts of a file, with the parts being specified by playback range, chapter, or whatever is required.

The wider application, that which addresses your original question and the more commonplace issues many of us have, is simply allowing the use of records not directly associated with files. In most applications, these would refer to the same thing as a file, if it existed, like an audio track or movie. It might even point to one file that does exist, it's purpose being to represent that file in another album. Applications include replacing lists with pseudo albums (so they can be tagged independently), replacing specific tracks in an album with pseudo files linked to files of better quality, wish lists (for any type of media), records of movies seen but not owned...

[rick.ca]

I was happily in the dark until I discovered that you can, in fact, select 'Playlist Group' when creating a view.  Why allow that functionality when the result is a complete reordering of any carefully compiled and sequenced playlists?  I still don't get it.  I don't want to 'tag' anything.  I just want it displayed in the order I had it.

I imagine the reason for this is simply because in a regular view the files are displayed according to the rules of the view rather than the rules of the playlist. I have no idea how difficult it would be to provide the means to sort the list in the original playlist order. But it's not obvious this is the behaviour desired. The purpose of displaying a playlist in a view may very well be to view the files it contains with all the rules of the view—including order and grouping. That's almost certainly the case if the 'Playlist Group' feature is being used to select multiple playlists to display. Perhaps a more "accurate" way to describe what's happening is the view is displaying the items in the selected playlist—not the playlist itself.

If you really don't want to tag anything, and you're satisfied to work with playlists alone, the better question might be, why can't we configure playlist views that have all the same characteristics of regular views (i.e., with Categories, Panes, Grouping, etc.)? But I doubt there would be much demand for that. I think what most who ask about this want is the ability to display a playlist along with other files in their regular view. That would be possible if one could create a pseudo album from a list. I realize that's not as convenient as directly displaying a playlist in a regular view, but it avoids all the issues inherent in mixing list entries and real files. It would also be done with a feature set that addresses a much wider variety of needs.

[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]

What do you think?

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.

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.

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]

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). 

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)