Print

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

[Jamil]

I am still struggling with the Stack feature.  I love the feature, and I think it is great.  What would make it even better is by automatically making the selection of files with the highest bit rate and/or bit-depth the target that all other selected files get stacked into.  The reason for this request is the order of clicks is currently very important to determine which file the others get stacked into.  Once it becomes more than two files you select, things always end up undesired and I must try this again until I get the correct results.

A suggestion:  how about a new option for stacking to allow the target to be chosen automatically?  This way if some people desire the currently implemented feature, they may continue as-is.

If no one cares about the current feature, then an option would not be needed at all.  A change to the current implementation would be less work.

Thanks.

[RoderickGI]

I am still struggling with the Stack feature.

Read the Stacks Wiki article again carefully. MC should be picking the largest file when you create a Stack, which in general should be the file with the highest bit rate and/or bit-depth, if the Tracks selected have the same duration and contain the same audio.

[Jamil]

Read the Stacks Wiki article again carefully. MC should be picking the largest file when you create a Stack, which in general should be the file with the highest bit rate and/or bit-depth, if the Tracks selected have the same duration and contain the same audio.

Either the wiki that contains this information is simply wrong, or this post above is incorrect.  This has never been the behavior of any version of MC I have ever used.  I will move this to a new thread.

[Jamil]

It's been claimed that stacks combines files with the largest taking precedence.  This has never been my experience with any version of MC.  The specific order of files clicked determines which files take stack precedence.  Here is an example below that I just reproduced with the latest build of MC 26.0.56.  Every version I have ever used with the stack feature has done this.  This is nothing new.

I have screenshots of the same song from two different CDs.  One is from the original album release, and the second is from a Greatest Hits CD.  File1 is smaller at only 16.4MiB, and File2 is larger at 19MiB.  Size makes no difference whatsoever in stack precedence.  What matters is the file selection order.  MC gets really goofy when three or more files are selected  to be stacked.  All bets are off then for consistency.

[vma]

That is already there. Top Menu > View > Audio Only Mode.  Or you could just switch to using MC for Video. 

You can also turn specific Feature on and off in "Options > General > Features".

I know, I turned Audio only mode on as one of my first settings. What I mean is that by splitting MC might be Audio version more "audiophile" focused, smaller size etc.

[wer]

Read the Stacks Wiki article again carefully. MC should be picking the largest file when you create a Stack, which in general should be the file with the highest bit rate and/or bit-depth, if the Tracks selected have the same duration and contain the same audio.

You can shift-click or control-click to select multiple tracks to stack.  The order in which you select them or click them does not matter. The size does not matter.

What matters is whichever track your mouse is over when you right-click to bring up the menu to select "Stack", then THAT track will be the top of the stack.

However, the Wiki article on stacks is kind enough to say this:
Stack and Unstack creates and destroys stacks, respectively. The underlying files are not physically affected, just their grouping inside of MC. When creating a stack, the top of stack starts out somewhat random. The application picks the largest file as the top for non images. For images it picks the largest dimension file of type jpeg.

That may have been true at one time, I don't know, but it is not true now.  The wiki is wrong.   And so is.... <cough> .... <mumble> .... no, I can't bring myself to say it.   

[RoderickGI]

How kind Wer.

In my defence, and did say:

MC should be picking the largest file when you create a Stack, which in general should be the file with the highest bit rate and/or bit-depth, if the Tracks selected have the same duration and contain the same audio.

I didn't test, so I wasn't silly enough to say it does do anything. 

But I did suspect that the right-click on the top file worked, as you have found. I think a careful search of the Release Notes would find a change that implemented that.

[wer]

Hey Rod! How are ya? 

I couldn't find it in the release notes, but I know a lot of people have been confused about it for a long time.  Honestly I don't really use the feature myself.  But your original reply was fair; indeed it should be doing that, because that's what the documentation says it does.  Oh well...

[Jamil]

So my feature request now makes sense to everyone and would make this feature intuitive?  Right now it is not.

[wer]

So my feature request now makes sense to everyone and would make this feature intuitive?  Right now it is not.

Well.... No.   I think it's far better for the user to have direct control over which item is the top of the stack.  And right now, you do.  An "automatic" method will confuse many people because they will not understand or be able to follow the rules it uses, so to those people the choice will seem random.  So they will be confused.

As it is now: whichever one you right click on and select stack, that will be the top of the stack.  Simple.

[Jamil]

Okay.  The feature will remain confusing only for those who use it.

The trick to getting it to work is to simply select the last file you want on the top of the stack, right click, and finally click Stack on that top file.  This is the faster way to get this to work.  Unfortunately, this is so un-intuitive and used so rarely by me, this explains why I always have to try this out about three or four times before it's correct.

Seems like a simple option to choose the file to stack into could help out here.  Even a custom filter for this selection for sort criteria could make this 100% more usable for my use case.  This doesn't even seem like a lot of work to implement.  It's just a matter of doing it.  This has been difficult for a very very long time now.  The fact that the wiki cannot even explain this properly also does not help.

[Jamil]

Direct control could be adding a sort filter for the user to select the stack order.  The filter may sort on whatever criteria the user chooses.  It can use the Smart Filter portion of the UI for sorting.  The first file of the sort becomes the file stacked into.  This would improve the feature, remove all confusion, and provide complete control to the end-user who uses it.

[JimH]

Auto stack may work differently than manually stacking.

[Jamil]

Auto stack may work differently than manually stacking.

Thanks for splitting this into a new thread.

I do not believe that many of your long-time users are using this feature at all.  If more people were using it, I am sure you would see more complaints about it.  I actually only learned about it being a feature when you mentioned it to me on these forums years ago.

I do not believe you have to worry about making it worse.  You have the ability to add auto sort as an option that may be turned on and off.  When I stack files in a specific order, this order will not change for me.  Having the ability to specify a specific stack sort order to be done automatically would be a huge time saver.

Since no one else is using it, it can only make things better...

[Jamil]

Just to be sure what I propose above is crystal clear--

Please see attached screenshot I borrowed from the Edit Smartlist dialog.

I am adding sort criteria with the intent being the first item from my selection is always selected to be stacked upon.  Add this new dialog, and have it default to no criteria at all.  With no criteria, there would be zero change to the existing behavior.  This would solve my reported issue, and the current list of users who are happy with the current behavior will see no changes...

 

[RoderickGI]

Actually Jamil, a lot of people use Stacks for various reasons, and while it takes a little bit to learn about them and how they work, not just the Stacking process, but also moving, renaming, and so on, most seem to use it with no issues. The Wiki is actually correct by the way, but not complete. Maybe I shall clarify it later on. Maybe not. Or you could write up what you think the Wiki should say, and I'll put that in the Wiki if you like. 

Anyway, I had a little time because, Coronavirus, so I had another look at the Stacks functionality. I only looked at audio Stacks. To do so I took a bunch of FLAC files and converted them to MP3, M4A, and APE files, so I had four copies of each. Note that this meant all files had identical metadata in the fields [Artist], [Album], [Track #], and [Name], which would be important when using Auto Stacking later.

I quickly realised that what I used to do was completely intuitive, because I just started doing it again with my sample files. It is as Wer said earlier. I selected the four files I wanted to Stack, clicking them in any order at all, then right-clicked on the FLAC file which I wanted to put on top of the Stack, and selected "Stacks > Stack" which correctly Stacked the four files and put the FLAC file on top. This worked every time, no matter what sequence I clicked the files. I used the same method to put MP3 and APE files on top of some of my Stacks. It all worked perfectly.

I then moved on to Auto Stacking. Again, I selected the four files I wanted to Stack, then right-clicked on any file and selected "Stacks > Advanced > Autostack Files by Name". At this point an interesting dialogue window popped up. See the attached image.

Now if I selected "Yes" in this dialogue, I was able to enter the File Type that I wanted at the top of the Stack. So if I entered FLAC, then the FLAC file was at the top of the Stack. If I entered MP3, the MP3 was at the top. Same for APE ad M4A. So this function works perfectly.

I tried again, and this time selected "No" in the dialogue. MC immediately Stacked the file and always put the FLAC file on top. Why? Because the FLAC file was always the largest file. So MC does indeed put the largest file on top if it isn't given any other instructions. As above, the Wiki is correct, if not complete. Closing that dialogue by clicking the close button "X" behaved the same way as clicking "No".

I did the same tests using the "Stacks > Advanced > Autostack Files by Artist, Album, Name" and "Stacks > Advanced > Autostack Files by Artist, Album, Track # and Name". They both worked as per the "Stacks > Advanced > Autostack Files by Name" function.

I then tested Stacking multiple songs, each four files, at the same time. So I selected twenty four files, which was made up of four copies of six songs, right-click on any file and selected "Stacks > Advanced > Autostack Files by Name". In the popup dialogue, if I selected "Yes" and gave MC a File Type to put on top, that is what it did.

Repeating the above test, if I selected "No" in the dialogue, MC put the largest file at the top, as expected. This was made even more obvious with some of my test files, where APE files were put at the top. On checking, indeed the APE files were larger than the FLAC files.



So, what is going on in your installation? Do you see the same functionality? More specifically, do you see the popup dialogue I show in the attached image?

If not I suspect that you have ticked the box "Don't show this message again" in that dialogue at some time. If you want to see this dialogue again, so you can use Stacks as above, go to "Options > General > Advanced" and click "Reset all confirmation messages". You will then see the dialogue again and can use the Stacks feature as above.


BTW, your desire to sort by the Bit Depth and then Bitrate is still valid. Putting the largest file at the top of the stack is an approximation of that, and in the case of the files I was using, where Duration and Bit Depth were identical, it was the Bitrate that determined which file was largest, and hence which file was put on top of the Stack.

However, given the above, do you still think you need that sorting option?

If you think any of the above is incorrect could you please provide a concise and precise way to replicate the problem you are seeing, in one post. If the problem can be replicated, maybe it can be fixed.

[wer]

You're a wiz, Rod.

I have never once used that function.   But I see there are actually several options on that Stacks->Advanced popup menu, as you mention:


I would think that would be enough to satisfy anyone that looked, especially given the direct control with their right-click in the beginning.

But I would still say the wiki is wrong.  What it did was equivalent to saying "eating a hot-dog is fatal" but leaving out the important "if you try and swallow it whole and it gets stuck in your esophagus and you suffocate." 

[Jamil]

I actually never used this function either, but here are some example of files I must stack.  I will use some from my Prince collection of music, since I have many duplicates at various bit rates and depths.  Please let me know if there is something intuitive that will work in this scenario. These are exact file paths, names, and the file's tags match portions of the paths.  You should be able to see which portion match up with specific tags.  It's obvious.

\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1984, Purple Rain (192kHz)\01-Let's Go Crazy.flac
+8 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1984, Purple Rain\01-Let's Go Crazy.ape
+8 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1985, Around The World In A Day (192kHz)\01-Around The World In A Day.flac
+8 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1985, Around The World In A Day\01-Around The World In A Day.ape
+8 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1986, Parade (192kHz)\01-Christopher Tracy's Parade.flac
+11 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince And The Revolution\1986, Parade\01-Christopher Tracy's Parade.ape
+11 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince\2015, Purple Rain Deluxe (Expanded Edition)\01-Let's Go Crazy (2015 Paisley Park Remaster).flac
+34 more files in location above
\\QNAPNAS\Media\Digital Audio\Prince\1993, The Hits\08-Let's Go Crazy.ape
+35 more files in location above

+ album after album after album with more duplicated music (Prince made a boat load of music when he was alive).

My tags match the paths above, and it makes fixing my tags easy using my batch tagger.  It looks like based on what you posted, this will not work for me.  Correct?  I have to manually stack as I have always been doing.  I intentionally have a lot of duplicates, because all these duplicates match the album.

My proposed feature would save me lots of time.  Do you understand now why it would?  I quickly select matches and my defined sort setting automatically takes care of what gets stacked into.  The proposals you guys are making about right clicking the top of the stack last takes too much time when I have so much stacking to do.  My tags are perfect now, and I do not wish to change them to work-around a cumbersome stacking workflow.

Key note:  my proposal saves time, as I already stated.

[Jamil]

Actually, looking at some other threads it appears that Matt may be looking for things to do!  I recall seeing a thread to enhance the MC scripting functionality asking for what can be added.  If he is looking for something to do, stacking needs help 

[wer]

Why don't you actually TRY these new Stacking methods you've never used, and see if you can make it work for you?

[Jamil]

Okay.  I will try and report back exactly what happens.

[wer]

It's not necessary that you report back, just that you try and use the information that's been given to you to help yourself.

Good luck.

[Jamil]

LOL

[RoderickGI]

My proposed feature would save me lots of time.  Do you understand now why it would? 

No. I can think of better ways to achieve what you want.

It appears that you have concatenated [Year], [Album] and [Sample Rate] to define a subdirectory, but you aren't doing it consistently, with Sample Rate left off sometimes, and other information such as (Expanded Edition) added for other files.

That is fine, but if your actual [Album] tag is, for example, "1986, Parade (192kHz)" then I would think finding duplicates and Stacking them would be much more time consuming than having accurate tags, using built-in Duplicate finding functions, and selecting the files easily because they are grouped together. But I don't know from your post what your actual tags are, or what the range of variations used are, I can only guess. It isn't obvious at all.

I quickly select matches and my defined sort setting automatically takes care of what gets stacked into.

I guess if you sorted by filename you could find the files to Stack quickly. The Duplicates function, or a Smartlist based on it, would give you a better start. The standard "Audio -- Task -- Possible duplicates" Smartlist is a good start. There have also been lots of threads discussing how to manage duplicates, and using Stacks for them is one choice. BLGentry has written some good stuff on the topic, though he is a little controversial sometimes. {Waving at Brian} 

The proposals you guys are making about right-clicking the top of the stack last takes too much time when I have so much stacking to do.

You know you could use the above Smartlist, and add in sorts based on Bit Depth and Bitrate, right? Then the file to put at the top of the Stack would always be at the top of each group of duplicates. You could also add in fields such as [Duration] which would help determine if a file was really a duplicate, or a different version altogether.

My tags are perfect now, and I do not wish to change them to work-around a cumbersome stacking workflow.

I don't know what your tags actually are, or how you use them. That's why you have to work this out, and I can't. But if your tags are based exactly on the subdirectory naming you use, they certainly aren't perfect.


It doesn't matter anyway. JRiver will either take up your suggestion, or not. I've explained in detail how Stack creation works, and shown that it wasn't as you stated. It's entirely up to you what you do with the information.


Have a look at the attached image. It shows the Duplicates Smartlist with extra sorting, and I've highlighted a couple of exceptions that would not be picked up by your sorting rules, due to Duration differences.

[Jamil]

Here is how my batch tagger extracts and creates files and paths based on my tags.  These are one to one:

<Artist>\<Year>, <Album>\<Track #>-<Title>.ape

Those are all tags above.

For this example:

Prince And The Revolution\1984, Purple Rain (192kHz)\01-Let's Go Crazy.flac

Artist = Prince And The Revolution
Year = 1984
Album = Purple Rain (192kHz)
Track# = 01
Titale = Let's Go Crazy

My music library is very old and started from ripping CDs.  There was no such thing as 192kHz releases when I started collecting music, so there was just a single release I had for a unique album.  Times have changed now, and I have high definition remasters of the same albums.  I have no desire to combine all the same song files into a single directory, so I added (192kHz) for a unique directory name.  The 16-bit files I use exclusively for my car.  The high def files I listen to on my DAC.  Do you now understand why it is not consistent?

For this example:

Prince\2015, Purple Rain Deluxe (Expanded Edition)\01-Let's Go Crazy (2015 Paisley Park Remaster).flac

These tags were set not by me, but I bought and downloaded this from HDTracks.  They set all these tag and file names, and I left them how they were set.  They (or more likely the estate of the artist) decided that the album name was to be: Purple Rain Deluxe (Expanded Edition).  I did not make this decision.  They also named the track:  Let's Go Crazy (2015 Paisley Park Remaster)

The music I wish to listen to on my computer is only the high def material, which is why stacking works nicely for me.

I think you stated it best with this comment:

JRiver will either take up your suggestion, or not. I've explained in detail how Stack creation works, and shown that it wasn't as you stated. It's entirely up to you what you do with the information.

I really am not even sure why you are against the change suggestion.  People have readily admitted that stacking confuses many users.  Heck, do you even use it?  I am not sure why you are even defending it.

[RoderickGI]

I really am not even sure why you are against the change suggestion. 

I'm not:

BTW, your desire to sort by the Bit Depth and then Bitrate is still valid.

I don't think your idea is a bad idea. If it could be made flexible, some people would use it. I suspect it won't get priority resources from JRiver. I never assume how much work any change would take to implement in MC, no matter how small and easy it would seem to be, so I only show support for an idea if I would really use it, and there was no other (or better) way to achieve the same or better result.

However when you said something about the functionality that was wrong...

It's been claimed that stacks combines files with the largest taking precedence.  This has never been my experience with any version of MC.  The specific order of files clicked determines which files take stack precedence.  Here is an example below that I just reproduced with the latest build of MC 26.0.56.  Every version I have ever used with the stack feature has done this.  This is nothing new.

... I correct it.

When users make statements about how the software is supposed to work, and say it doesn't, other users are going to read that and not try to understand how the functionality works. Your misunderstanding is therefore spread to other users. That means less satisfied users of MC, which could mean less revenue for JRiver, which could mean that the software I like to use has a shorter future than I would like. Stacks functionality works, as described, I'm just making sure all other readers/users know that.

I also just think what you are trying to do can be done better, and I explained how.

Heck, do you even use it? 

I thought I clarified that in the original thread. Perhaps it was lost when this thread was split out. Yes, I have used Stacks on and off for some time. Particularly when I used to use the audio cache functionality for Handheld Sync, but also when sorting out a lot of mp3 files that had since been replaced with new flac rips. So, yes, I use it, but not so much lately. Does it make a difference to my explanations? I don't think so.

I am not sure why you are even defending it.

As above, I'm not. I've just been explaining how it works, clarifying some misunderstanding you had of the functionality, and suggesting how you could improve the overall process, rather than just one small part of it.


As above, it is up to you whether you use the information I have shared, and up to JRiver whether they take up your suggestion. I have no influence over that.

[Jamil]

I'm not:
I don't think your idea is a bad idea. If it could be made flexible, some people would use it. I suspect it won't get priority resources from JRiver.

I commonly see posts such as above with change requests or ideas I have.  I understand the development process and prioritizing.  Honestly, this idea I am suggesting would be much more valuable and usable than the HDCD time effort.  I could probably add several more implemented features to this list 

I recall once I made a request to reduce the size of album art shown in MC's Playing Now view.  Others here similar to you basically stated something along the lines of "Good luck with them actually working on that."  When I read that and actually took the time to learn how to do it myself, I actually learned it and resolved the issue myself.  I shared my solution with the world afterward.  Guess what happened next?  JRiver decided to implement my suggestion, and they made changes to MC to reduce album art size with portions based on my own solution 

Maybe I will have to write a plugin that handles stacking better than JRiver does it out of the box...

[RoderickGI]

That's cool Jamil.  I would suggest continuing your lobbying before building a plug-in, though. As you say, Matt has been very responsive lately.

Maybe an "Auto Stack by Wizard" feature, like the Search Wizard would be well received.


I wouldn't have responded to this thread at all, and left you to garner support, if you hadn't been wrong about the existing functionality. Now that is sorted, all is good.

I was serious that you could update the Wiki article if you think it is wrong. Anybody can request access to do that. Jim would be happy to have more people writing and updating articles. Or if you write it, I will update the page.

[Jamil]

Maybe an "Auto Stack by Wizard" feature, like the Search Wizard would be well received.

Unfortunately, the logic needed to do this properly is so complex that a new 'Wizard' will not be effective.  Easy Wizards are good for some situations, but not this one.  A black box solution is a bit too big of a project and not worth the development effort or time.  Smaller feasible approaches, such as my proposal, works better.  Also, they do not force users to change my particular media file storage layouts (such as particular file names, folder names and tags).

[RoderickGI]

Language and effective communication. It is such a personal, experience based, and sometimes difficult thing.

Here is an image of the MC Search Wizard, with a couple of fields filled in. Does it look familiar?



"Auto Stack by Wizard" like the Search Wizard was just my shorthand way of describing your solution. I know, it doesn't require the Rules section.

[Jamil]

I am continually installing all the latest updates to MC26, and I am seeing that there was a change made to stack functionality that I did not see listed in the change notes.  I am not sure exactly when this change was made (version), but now I am able to select a specific file type to become the top of the stack.  This is an alternate implementation that will help in many (but not all) of my scenarios I posted above.  I am also seeing stack error checking also exists that shows a report of potential errors.

Thank you, J River, for making this change.