Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Basic error in numerical sorting of album names
16-01-2014, 17:36
Post: #31
RE: Basic error in numerical sorting of album names
(16-01-2014 02:21)Andre Gosselin Wrote:  Playlists names are just file names with the extension removed, and the sad fact is that, under Windows, the file names would correctly sort without the leading 0's in the work numbers. Similarly under Linux, if directory contents is listed using "ls -v" command. With this in mind, I risk the following suggestion :
Implement an option applicable to browsing the [folder view], allowing the user to either use the current sort technique, or sort using the underlying OS commands known to "generally" produce what is for some a more "natural" sort order (eg "ls -v" on Linux, default directory listing on Windows). Minimserver could run this command in the background, and pipe its output in place of what the current sort procedure generates. (I am guessing a bit here, but I used this technique a lot when I was programming in the Python language). Of course, in doing so, a user must be ready to accept whatever nasty results this may produce in some circumstances.

Because the folder view is just a way to look the OS directory structure, I think it would be acceptable to allow recourse to some OS specific internals to generate a directory listing. For an example along the same line, some characters are not allowed inside filenames on Windows (colons for ex.), but they are on Linux. Consequently, the OS requirements must be taken into account when playlists are named.

I understand that this suggestion does not apply to the album tags sorting issue, but it could certainly alleviate the similar playlist sorting issue.

Regards

Thanks for this description of how you are using playlists. Your suggestion of using an OS directory listing would work for folders that contains only playlists, but it wouldn't work for folders that contain any other items. This is because folder view uses the Title tag of the item for display and sorting purposes, not the filename of the item. Playlists are a special case because they don't have a Title tag, so MinimServer uses the filename as the title.

Also, I would prefer to keep the browsing behaviour of MinimServer (including how lists are sorted) consistent across all platforms. The Java-based implementation currently ensures this. I think cross-platform consistency in the browsing experience is a key feature of MinimServer, and I wouldn't wish to change this unless absolutely necessary.
Find all posts by this user
Quote this message in a reply
16-01-2014, 19:26
Post: #32
RE: Basic error in numerical sorting of album names
(16-01-2014 17:36)simoncn Wrote:  
(16-01-2014 02:21)Andre Gosselin Wrote:  Playlists names are just file names with the extension removed, and the sad fact is that, under Windows, the file names would correctly sort without the leading 0's in the work numbers. Similarly under Linux, if directory contents is listed using "ls -v" command. With this in mind, I risk the following suggestion :
Implement an option applicable to browsing the [folder view], allowing the user to either use the current sort technique, or sort using the underlying OS commands known to "generally" produce what is for some a more "natural" sort order (eg "ls -v" on Linux, default directory listing on Windows). Minimserver could run this command in the background, and pipe its output in place of what the current sort procedure generates. (I am guessing a bit here, but I used this technique a lot when I was programming in the Python language). Of course, in doing so, a user must be ready to accept whatever nasty results this may produce in some circumstances.

Because the folder view is just a way to look the OS directory structure, I think it would be acceptable to allow recourse to some OS specific internals to generate a directory listing. For an example along the same line, some characters are not allowed inside filenames on Windows (colons for ex.), but they are on Linux. Consequently, the OS requirements must be taken into account when playlists are named.

I understand that this suggestion does not apply to the album tags sorting issue, but it could certainly alleviate the similar playlist sorting issue.

Regards

Thanks for this description of how you are using playlists. Your suggestion of using an OS directory listing would work for folders that contains only playlists, but it wouldn't work for folders that contain any other items. This is because folder view uses the Title tag of the item for display and sorting purposes, not the filename of the item. Playlists are a special case because they don't have a Title tag, so MinimServer uses the filename as the title.

Also, I would prefer to keep the browsing behaviour of MinimServer (including how lists are sorted) consistent across all platforms. The Java-based implementation currently ensures this. I think cross-platform consistency in the browsing experience is a key feature of MinimServer, and I wouldn't wish to change this unless absolutely necessary.

Thanks Simon. I fully understand your viewpoint. I will stick to the leading 0's approach until maybe something changes in the future.

Regards
Find all posts by this user
Quote this message in a reply
28-04-2014, 19:25 (This post was last modified: 28-04-2014 19:27 by simoncn.)
Post: #33
RE: Basic error in numerical sorting of album names
This feature is now available in MinimServer update 25. See below for comments on the issues that I mentioned previously.

(13-01-2014 08:55)simoncn Wrote:  1) Given that this feature does involve some extra cost, it needs to be optional and it needs to be implemented in a way that doesn't cause overhead for users who don't have the feature enabled. Also, it is very desirable that it doesn't cause overhead when sorting strings that don't contain embedded numbers.

I believe the overhead of the implementation I have used is small enough to allow this feature to be to be enabled by default. I have also provided a property to disable the feature in case it causes any problems.

Quote:2) It needs to be well specified. For example, is '00' greater or less than '0' and is '01' greater or less than '1'? These strings cannot be considered exactly equal because this would violate the principle that comparison operations should be consistent with equals, as explained on this page. The case of '0' and '00' is relevant for classical music, as there are two Bruckner symphonies with these designations.

The comparison algorithm operates in three stages:

1) Remove leading zeros from the numbers to be compared and count how many were removed from each number
2) Compare the numbers with leading zeros removed
3) If these numbers compared equal, the number with the larger number of leading zeros removed is regarded as the smaller number

Quote:3) It needs to be able to be combined with other features, such as the existing 'ignoreThe' capability, and also with any other custom sorting features that might be added in the future.

This feature is implemented within the sort comparison algorithm, so it shouldn't interfere with any sort value customization features.

Quote:4) It needs to fit in with the existing design and implementation of MinimServer, without causing too much internal complexity in the code.

The chosen approach is (just) on the acceptable side of the limits for this criterion.

(13-01-2014 11:48)simoncn Wrote:  5) The ability for the user to override numeric sorting for individual items where the number recognition algorithm would produce a sort order that isn't what the user wants.

This isn't as straightforward as it sounds. The user would expect to be able to do this override by adding an ALBUMSORT tag with the value of this tag being used to do an alphabetical comparison. The problem is that it isn't possible to mix numeric and alphabetic comparisons without violating the total ordering contract of the comparison operation: if a is less than b and b is less than c, then a must also be less than c.

To preserve total ordering, it would be necessary to either do numeric parsing of the ALBUMSORT value (which defeats the purpose of the manual override) or convert the parsed numeric values of all other items into equivalent sortable alphabetic values where the numbers are padded with some predetermined number of leading zeros (so 7 might become 00007 and 456 might become 00456). I don't think either of these approaches would be satisfactory.

The chosen approach does numeric parsing of the ALBUMSORT value. This is the only practical solution. If the user wants to ensure a particular sort position by adding an ALBUMSORT (or similar) tag, he/she must understand how numeric sorting works and create an ALBUMSORT tag value that produces the correct sort position.
Find all posts by this user
Quote this message in a reply
29-04-2014, 09:12
Post: #34
RE: Basic error in numerical sorting of album names
Many, many thanks Simon for implementing this upgrade.

It may seem trivial or irrelevant to many, but now my Bach cantata albums are displayed in the correct order!
As regards sorting you are now in the same class as JRiver and iTunes, but overall your software is preferable - cleaner appearance, easier to understand and faster.

Keep up the good work.

System: ALAC iTunes library on Synology DS412+ (running MinimServer) > Airport Extreme bridge > Optical isolation > dCS Network Bridge (controlled by Galaxy Tab S2 tablet running BubbleUPnP&Mosaic) > PS Audio DirectStream DAC > Primare A60 > Harbeth SHL5plus 40th Anniversary model
Find all posts by this user
Quote this message in a reply
30-04-2014, 22:40
Post: #35
RE: Basic error in numerical sorting of album names
(29-04-2014 09:12)DavidL Wrote:  Many, many thanks Simon for implementing this upgrade.

It may seem trivial or irrelevant to many, but now my Bach cantata albums are displayed in the correct order!
As regards sorting you are now in the same class as JRiver and iTunes, but overall your software is preferable - cleaner appearance, easier to understand and faster.

Keep up the good work.

Thanks very much!
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)