Print

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

[Alex M]

If the tag "Track #" contains characters other than numbers, this information is not entered in the corresponding field of the JRiver library. In this case, the songs are played in the wrong order, which is completely unacceptable.
However, the function Tag(Track #) correctly reads the information.
Can this be fixed?

[RoderickGI]

The MC Library field, [Track #] is an integer value. That isn't going to change. It will always be an integer numeric value.

It seems that the files you have include tags called "Track #", and those tags contain non-numeric values. So MC will never import them into the Library.

So, just create a new String type field in MC, call it "#" if you wish, and assign the expression you used for it, and then change your Views to use [#] instead of [Track #]. Of course, there is functionality built around the [Track #] field, so you will lose that. But if you want to use alphanumeric values for track number that is one of the consequences.

Of course, you could just use the [Disc #] field to designate side, but that is also an integer. So you would have to use side 1 and 2 rather than A and B.

Or you could create a new field such as [Side] and populate that with the A and B sides, then include them in Views.


Lots of options. Some good, some bad. I suggest that you search the forum for what other people have done to manage Side A & B for Vinyl recordings. There are probably some good ideas out there.

[Alex M]

Why not change the format of the [Track #] field? What is the meaning of this restriction?

[DJLegba]

Why not change the format of the [Track #] field? What is the meaning of this restriction?

Your system will fail when there are more than 9 tracks on a side. You'd have to use A01 through A10 etc to get them to sort correctly. Everyone understands how numbers sort. Most people do not expect strings containing numbers to sort the way they do - eg "1", "10", "2", "3", etc.

[Alex M]

As far as I remember, starting with Windows Vista the sorting is performed correctly.

[DJLegba]

Are you sure Windows isn't sorting the files by date? When it sorts by # you'll see that indicated in the header row.

[Alex M]

I'm sure.
Sort about which you wrote was in Windows XP.
.

[swiv3d]

I think you will find that windows requires the track value to be an integer. So JRiver are just conforming to an industry standard.

[RoderickGI]

Why not change the format of the [Track #] field? What is the meaning of this restriction?

Well, I don't speak for JRiver, but can you imagine how many people are using expressions in MC that rely on [Track #] being an integer, not to mention built-in functionality? I know it is a lot. Integer sorting and math, hence expression evaluation, is much faster than breaking down an alphanumeric value into components and sorting each component separately, which is what Window 10 does now. The speed of the MC Library is one of its greatest selling points, so JRiver probably doesn't want to compromise that.

Changing the Windows sort algorithm for file names probably had lots of people sighing with relief, and a whole bunch tearing their hair out as they had to fix their applications, systems, and processes/workflows. Could you imagine a large database application supplier suddenly saying, "Oh hey, we are going in change this primary key to your database from an integer to a string, but you can all fix your validations, sorting, views, reports, queries and so on easily, can't you?". It wouldn't go down well I think.

I'm not saying it is impossible. Just don't hold your breath. After all, it is the Track Number. No doubt someone from JRiver has read this thread and is aware of your request.

I suggest you select an alternative method of recording the vinyl side, and fix your source data in the files.

I think you will find that windows requires the track value to be an integer. So JRiver are just conforming to an industry standard.

Indeed it does. Only the name sorting was changed to take into account examples such as above.

[Alex M]

In recent years, the popularity of vinyl is growing. Some artists even do special mastering for vinyl releases. And this, as a rule, quite expensive two-disk editions. However, with all the undoubted merits and, first of all, much higher quality of sound, the poor wear resistance of vinyl has not disappeared anywhere. Therefore, many immediately make a digital copy for everyday listening. At the same time, true vinyl lovers prefer the original numbering of compositions.

I hope that the creators of JRiver will pay due attention to this problem.
If developers are concerned about the compatibility problems or the amount of work needed, you can simply add one more field of the track number, in which the full information will be inserted when importing. Then the user can choose which field to use.

[Spike1000]

If developers are concerned about the compatibility problems or the amount of work needed, you can simply add one more field of the track number, in which the full information will be inserted when importing. Then the user can choose which field to use.

My 2p. Use a 3rd party tool such as MP3Tag to bulk populate (ie copy one field to another) a custom field in your source files before you bulk import into MC. It would only take a few minutes. (Could also be done retrospectively)  Bulk change the Track# Tag to an integer at the same time. With saved 'Actions' in MP3Tag it can even be automated!

Create a custom field (of the SAME name) in MC as has already been recommended. Then when you import you have track numbers that sort like the rest of the world and also a populated custom field that can sort that suits your personal preference. You can then customise the views to show your preference and hide that nasty track integer forever 

Spike

[Alex M]

When I make a vinyl rip, I myself write the file names and fill in the tags. And insofar as I do it that way, then it's important. I rather use players with no problems with reading tags for vinyl rips, than I will refuse the classical numbering.
_

[RoderickGI]

What does Abbey Road by The Beatles, with 11 tracks on the B side, look like in Foobar and Tau Player?

[Alex M]

foobar & tau

[RoderickGI]

That is a "Display Title" in Foobar isn't it? Which is actually a concatenation of various tags into a string for display? If so, the actual sort is defined separately, and so I guess the image doesn't show the real basis of the sort.

Also, the definition of "Track #", known as %tracknumber% in Foobar is;

%tracknumber%
Two-digit index of specified track within the album. Available only when "tracknumber" field is present in track’s metadata. An extra '0' is placed in front of single digit track numbers (5 becomes 05).

How did you fit "A11" into a two digit index?

The alternate tag is %track number%, which is;

%track number%
Similar to %tracknumber%, however single digit track numbers are not reformatted to have an extra 0.

Which also wouldn't hold the value "A11".

Sorting in Foobar also seems to be defined by concatenating tags together, such as;

%ALBUM ARTIST% - %DATE% - %ALBUM% - %DISCNUMBER% - %TRACKNUMBER% - %TITLE%

I don't use Foobar so don't know the ins and outs, but it seems that Foobar is using Disc # and Track # in exactly the same way MC is, which is the industry standard; Numeric values. Maybe it is doing something tricky that I didn't find in my quick Google. But I could create displays such as shown in Foobar using a custom field as described above, and existing functionality.

This thread is a bit old, but it is discussing exactly the issue you have, and the proposed solutions for Foobar are exactly as we have described above.
https://hydrogenaud.io/index.php/topic,49594.0.html

So, has Foobar added functionality to handle vinyl sides since then? Do you have a reference you can share?

Here's another from 2015. Same problem, same solution. Track numbers are numeric and so sort correctly.
https://www.reddit.com/r/foobar2000/comments/36w2p1/anyone_else_organise_by_vinyl_side/

I haven't found anything that suggested Foobar would accept alphanumeric values in %tracknumber%.

Another example for Logitech Media Server in this case, from 2012. Same issue. Same solutions. Track Number is numeric, because it is an industry standard.
https://forums.slimdevices.com/showthread.php?98935-Is-it-possible-to-sort-by-combined-alpha-numeric-combination&s=a8d350531ce8261ee87edb164d3e57ad

I haven't looked at Tau in detail, because I've done enough Googling for you. I wouldn't be surprised if it was exactly the same situation as Foobar.


If all the examples I could find for the same issue are using the same solution, why can't you use that solution in MC?

[Alex M]

I do not know how foobar works, I just picked up the version that I liked by its sound. And I also downloaded the shell with DeviantArt.
But even the basic version opens the files in the correct order.

As Tau sorts, I can ask its author.

There is no industry standard for the format and size of the field with the track number for audio files, such as wav, flac ...

[Alex M]

What is interesting is that the JRiver itself correctly sort alphanumeric fields.
 

[RoderickGI]

What is interesting is that the JRiver itself correctly sort alphanumeric fields.

Correct. When it is sorting an alphanumeric field. Your image in Reply #4 already showed that.

That is why we have been suggesting creating a new field to contain your SideTrack values, and sort by that, as per the first reply to this thread, which I wrote. Go back and read it. You can even load the new field using the Tag() function, as shown in your original post. All of which is why I reiterated in Reply #14 what everyone else who has come across the problem has done to solve it.

But in all the solutions the [Track #] tag has remained an integer, because that is the industry standard (by convention if not by written standard) even if the heading on a column says "Track no" and the column contains alphanumeric values, because that column is not actually the Track number, but some manipulation of it, or another field/tag that is the result of a concatenation of tags, or an expression.

You have the solution. You have had it all along. So why not just implement it?

[Alex M]

You have the solution. You have had it all along. So why not just implement it?

This solution has a significant drawback. The result of the Tag(Track #) function can not be saved to the Library automatically. This means the JRiver will read the track number from each file every time. This is not good.

[ferday]

This solution has a significant drawback. The result of the Tag(Track #) function can not be saved to the Library automatically. This means the JRiver will read the track number from each file every time. This is not good.

Of course it can be saved.  Any custom tag can be saved

Foobar doesn't allow non-integer track # tags (ID3 requires 2 digits)
https://hydrogenaud.io/index.php/topic,49594.0.html

in MC, use the tag dump to find out where these alphanumeric track numbers actually are (hint: not in track #).  Once you know where you've put them you can easily and automatically import them into the library

[Alex M]

Of course it can be saved.  Any custom tag can be saved

But only by hand. And it's long and silly to fill in several hundred fields manually.

Foobar doesn't allow non-integer track # tags (ID3 requires 2 digits)
https://hydrogenaud.io/index.php/topic,49594.0.html

A reference to some ancient version, which is more than 10 years old. For a long time already, foobar supports ID3v2 tags in which there is no such restriction.

in MC, use the tag dump to find out where these alphanumeric track numbers actually are (hint: not in track #).  Once you know where you've put them you can easily and automatically import them into the library

In my opinion, this is not true. Can you give a concrete example?

[Spike1000]

But only by hand. And it's long and silly to fill in several hundred fields manually.

RoderickGI, It looks like Alex has 'Come A Long Way Baby'; but unfortunately he still has some way to go for that lightbulb moment

Spike

[Alex M]

About metadata formats.
For audio files, two tag formats are usually used: "RIFF LIST INFO" and "ID3v2"
TagID for track number "ITRK" and "TRCK" respectively.
And in both specifications it's frames of arbitrary format and size.

For greater compatibility, tags in real files are often written in both formats, as in the example below.

[RoderickGI]

ID3v2.0¹

TRK
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9".

ID3v2.3²

TRCK
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9".

ID3v2.4³

TRCK
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This MAY be extended with a "/" character and a numeric string containing the total number of tracks/elements on the original recording. E.g. "4/9".

The bolding is mine. It seems that the specification has been consistent. Always a numeric tag. Of course, that doesn't mean that some tools won't allow an alphanumeric value to be stored in the tag, as shown in your last image.

My understanding is that the RIFF format is pretty much freeform, sort of like XML, where the content is described in "Chunks" along with the actual data. So ITRK might have been used as the Track Number, and was added to FFmpeg⁴ for Wave files, but that was driven by the look of it by Foobar and Windows Media Player, rather than a standard. The original RIFF tag for Track Number was IPRT⁵,⁶.


Basically, ID3v2 is an accepted standard. Tagging using RIFF has some accepted practices, but isn't really a standard (If you believe that it is, could you provide a reference to the standard please?) For example, Audacity says "Track Number (ITRK) (not specified in the original RIFF standard but players supporting LIST INFO tags often support it)".⁷


Alex, as you have said that you are entering the tags yourself, it is apparent that the tool you are using allows alphanumeric values in the TRCK tag. Could you share which tagging tool you are using?

Also, I would like to have a look at one of your files that has been tagged using your method. Could you zip up a small example and share it on the thread? I think that could give us a way forward.

Thanks



Spike:      Nothing like a bit of robust discussion to keep the brain working well. 


References:
1. http://id3.org/id3v2-00
2. http://id3.org/id3v2.3.0
3. http://id3.org/id3v2.4.0-frames
4. https://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-April/076010.html
5. http://age.hobba.nl/audio/tag_frame_reference.html
6. http://www.bass.radio42.com/help/html/7e1a8908-88bd-d54b-77d7-f0d08466284c.htm
7. https://wiki.audacityteam.org/wiki/WAV

[Alex M]

Specification ID3v2 is written somewhat vaguely, and the description "numeric string" used in it is not a standard data format, but still implies the use of symbols in this field. The "/" character is a string character and can not be entered in a numeric field. Also there is no limit to the number of characters.
And if it so, why not use this field to your advantage, namely, to indicate the number of the song as it is written on the original.

I use foobar to make tags.
10 seconds of silence. Track number: A1

[Spike1000]

Interesting. . . MP3Tag sees and can write A1, B2 etc  in the Track field. For wav, flac and MP3.
However, once there are letters present it breaks the sort function for that column. . .  So yes it's possible to store letters and numbers in the track field but it breaks things.*

MC doesn't allow letters and number in the track field (but we know that, that's why we're here) if it did, it would probably break things.*

I'm still not sure why Alex just doesn't just create a custom field in FooBar/MP3Tag and bulk populate it with his A1 A2 etc and follow the convention of numbers in the Track field. Would mean his files would sort/play/import correctly in ALL players and with a one off customisation of the player they would display the way he wants them too. I think he thinks its a big piece of work when it really isn't even for 1000s of files.

Spike

* Just because you can doesn't mean you should.

[Fitzcaraldo215]

Specification ID3v2 is written somewhat vaguely, and the description "numeric string" used in it is not a standard data format, but still implies the use of symbols in this field. The "/" character is a string character and can not be entered in a numeric field. Also there is no limit to the number of characters.
And if it so, why not use this field to your advantage, namely, to indicate the number of the song as it is written on the original.

I use foobar to make tags.
10 seconds of silence. Track number: A1

I don't think "numeric string" with the allowable, optional addition of "/" in id3 is vague at all. Numeric means numeric.  Calling it a "string" allows for the optional slash, as opposed to just always a simple integer value, and it in no way means or implies that other non-numeric characters are allowed.

Be that as it may, in the tagging of thousands of albums, the Track Number/Disc Number fields in JR work perfectly fine.  We don't need JR to even consider supporting the slash.  And, we don't need JR trying to imitate Foobar and its lackadaisical implementation of standards.  If you prefer Foobar, knock yourself out.

[swiv3d]

Rah,Rah Fitzcaraldo215!! Maxwell's Silver Hammer (Track A3) should come down on this thread.

[JimH]

Cue sound of thread closing ...