[quote=JDany]It would be nice for Jaikoz to sort track numbers without leading zeros correctly. Most of my current Mp3 have 1, 2, 3 instead of 01, 02, 03 and they just sort in the wrong order.
Id forgotten about this, Ill fix it. In the meantime you can use Action/Local Correct/Correct Tracks to zeroise tracks less than 10 (8 ->08) which will mean sorting is correct as long as the track isnt greater than 99. But be careful the default settings in Action Settings/Local Correct Settings/Track Settings will lose the total no of tracks (see below), you need to enable the 'Sometimes Track No are displayed in the form track/total) - will enable ths option by default in the next release.
This total is actually held in the same field for Mp3s and Mp4s and isnt used in OggVorbis. So if your file contains a total number of tracks it will be shown in the Track No field in the form trackNo/TotalTracks
Just wanted to echo this request. I’d especially like to, for example, sort by artist, then by album, then finally sort the tracks within each album by track number. It’s frustrating to sort by album then have the tracks all jumbled, especially when I have to figure out which one of 20+ tracks is missing.
[quote=rmgarnett]Just wanted to echo this request. I’d especially like to, for example, sort by artist, then by album, then finally sort the tracks within each album by track number. It’s frustrating to sort by album then have the tracks all jumbled, especially when I have to figure out which one of 20+ tracks is missing.
Thinking about this problem a bit more, a trivial fix that I’d be perfectly happy with would be making the routine that sorts the rows of the table by the keys in a column stable. Collections.sort() is guaranteed to be stable; not sure what Jaikoz is using. But if the sort were stable, I could click to sort by track number, then click to sort by album, and everything would be awesome.
Yeah, so a sorting algorithm is stable if when two entries have the same key, their original order won’t be affected by the sort. java.util.Collections provides stable sorting methods, but obviously I have no idea about the internals of Jaikoz, but Collections.sort() just requires a List and a Comparator (or the Comparable interface). I’d guess we’re just sorting Strings in most cases, though?
The functional result would be, e.g., that if I sorted by track number, then by album name, all tracks with the same album name would remain in the correct track order (since the sort by album name would not modify the original order [by track number] of the tracks with the same [album] sort key).
Thanks! Great product, by the way! I spent months looking for a decent tagger for linux, and I finally found one that’s more than decent, but superb! No longer do I have to run vmware and export my music over smb just to tag my collection.
I think your example of stable sorting algorithms versus Jaikoz Sorting Algorithm is a bit misleading, Jaikoz is already stable within a single column. If you sort by a particular column, it always orders identical values based on the record number, so ordering by a column is completely consistent.
Now what you want it to do is consider any previously sorted column when sorting a new column, so if you sort by track and then by album it should sort preserve the track no when ordering identical albums. I can see why this seems like a good idea but this would break the stability of album sorting because albums would then be sorted in a different order depdning on the contents of the last column sorted (if any) rather than on the record no as happens now.
In this particular case it would seem to be useful, but if you reversed things so that you sorted by album first and then by track no it wouldn’t work because albums would get split up because within an album all track nos are different. So sorting by Track/Album acts like mutiple column sort but sorting by Album/Track doesnt - an inconsistency.
What you may want after sorting by album, is to sort tracks nos whilst keeping within the album. But this is a proper multi-column sort and we need a change in the gui to allow us to differentiate between multiple column sort to do this or there would not be a way to sort tracks without reference to the album.
So, I dont think I can do anything until ive figured a way of supporting multiple sorting in the GUI.
You’re correct that sorting by a single column preserves the record number ordering, but that’s not very useful. When I load an entire directory, the record numbers assigned to the files loaded seem almost arbitrary and certainly aren’t useful in any way. I see no reason why I would ever want to sort my albums “on the record number.”
No, it shouldn’t preserve the ordering from the previously sorted column, it should merely preserve the previous ordering (whatever it was) when two items have the same key in the current sort.
This is not an inconsistency. It’s perfectly correct behavior. You HAVE to split up albums when sorting by track number. It’s not inconsistent, it’s just that it’s not very useful to sort by track number and then by (ie breaking ties by) album. Although if you really want to see all the track numbers 01, 02, etc. sorted alphabetically by album, this would give you exactly that.
Esentially, the GUI component should simply say “Sort my tracks by: [key 1], break ties with [key 2], break further ties with [key 3], etc.” Then, if the sort is stable, this can be implemented simply as
ie by stably sorting the columns according to the specified keys in reverse order. So if you want to sort by track number, but have tracks with the same track number sorted by album (the weird example you gave), the user could input that and you could
Equivalently, the user could click the column sort button for album, then by track number. Making the sort stable (according to the previous ordering, NOT the record number) gives the users the expected behavior and makes implementing a GUI multicolumn sort trivial for the implementor.