INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: allenz on April 16, 2014, 02:03:05 pm
-
Hello everyone,
I have been evaluating JRiver on Windows (19.0.117) and just tried importing my music library. To my surprise, there are semicolons added to the end of some song and album names. Some albums were even split into two because some of the songs in the album have the album with a semicolon at the end, and some do not.
Does anyone have any idea why this happens? When importing the songs in iTunes or Windows Media Player, I don't see any semicolons.
Allen
-
Try editing the album names in the tag.
-
I can certainly try to go through and remove them, but I don't relish the thought of looking through 17000 music files. Find and Replace would be a conceivable option but I don't think regular expressions are accepted there.
-
You can use MC's full Expression Language inline in any field.
So, for example, if you select some files and edit the [Comment] field and type:
=FixCase([Name], 3)
That will replace the existing [Comment] field, for any files selected, with the Uppercase of the [Name] field. So, RegEx() (http://wiki.jriver.com/index.php/Media_Center_expression_language#Regex.28.E2.80.A6.29:_Regular_expression_pattern_matching_and_capture) is certainly available.
I'm not sure, at all, why this would have happened. MC does use, in certain fields (but not the ones you listed, generally), semicolons as a list delimiter. So, for example, [Keywords] is a list-type field, and semicolons are used as the delimiter.
[Artist] is a list-type field, as is [Genre], though they're treated somewhat specially.
But, it would only import what is actually in the tags in the files. There must be some reason (probably bad data in the tags) that this happened with some of your files.
-
The function RemoveCharacters() (http://wiki.jriver.com/index.php/Media_Center_expression_language#RemoveCharacters.28.E2.80.A6.29:_Removes_a_list_of_characters_from_a_string) might be easier for you to use for this purpose than RegEx(), by the way.
It would be good to know what might have caused it, though. Any way you can post an example file that was affected? If you don't have access to a "public link" service like DropBox, you can use Wikisend (http://wikisend.com/) for free (without even creating an account) up to 100MB.
-
I would have just used: =RemoveRight([Name],1) if all that has happened is a semicolon being added to the end of the name.
Very strange though.
-
I would have just used: =RemoveRight([Name],1) if all that has happened is a semicolon being added to the end of the name.
Yeah, I wasn't sure if it was ALWAYS at the end.
The other problem then is that you'd have to find them all first, otherwise you'd remove valid characters from the tail of the tag. If you just don't want semicolons in the [X] tag for ANY file, you could do them all at once with RemoveCharacters().
-
I have taken a closer look at the files.
The problem seems to be with how JRiver interprets padding at the end of the song or album name in the id3v2 tags.
The following file, for example, has two 00 bytes at the end of the album name "That's Right". In JRiver I then see a semicolon.
0000050: 4200 0000 0f00 0000 5468 6174 2773 2052 B.......That's R
0000060: 6967 6874 0000 5443 4f4e 0000 0006 0000 ight..TCON......
In contrast, in the following file there is no padding so there is no semicolon.
0000030: 6e74 7279 5441 4c42 0000 000d 0000 0054 ntryTALB.......T
0000040: 6861 7427 7320 5269 6768 7454 434f 4e00 hat's RightTCON.
Here is a sample file.
semicolon.mp3 (http://wikisend.com/download/649422/semicolon.mp3)
Thank you for your suggestions as to how to fix this. Wouldn't these suggestions, though, just affect the display of the tags? The semicolons would still be there, and JRiver would add semicolons when writing back to the file.
Any chance this could be changed? I am not sure whether or not these tags can be considered valid id3v2 tags or not, but it nevertheless seems strange to add the semicolons.
-
Thank you for your suggestions as to how to fix this. Wouldn't these suggestions, though, just affect the display of the tags? The semicolons would still be there, and JRiver would add semicolons when writing back to the file.
No, when you modify any field within MC, it modifies the Library (http://wiki.jriver.com/index.php/Library). And in MC, the Library is always "The Truth".
Also, the default option is to write changes to the file tags, as well, so this should (in theory) fix the broken tags in the files. Unless, of course, you've disabled:
Tools > Options > General > Importing & Tagging > Update tags when file info changes
Any chance this could be changed? I am not sure whether or not these tags can be considered valid id3v2 tags or not, but it nevertheless seems strange to add the semicolons.
Agreed. With that detective work, and the sample file, I don't see why not. You'll probably have to wait for Hendrik or someone from JRiver to see this thread and investigate, but I'd say chances are good.
-
Thanks for your help! In the meantime I have tried adding a RemoveCharacters expression as an auto-import tag. I had to create a new library (reimporting into the old one did not refresh the tags) but the semicolons are all gone!
Phew - glad that JRiver can handle this.
-
The following file, for example, has two 00 bytes at the end of the album name "That's Right". In JRiver I then see a semicolon.
0000050: 4200 0000 0f00 0000 5468 6174 2773 2052 B.......That's R
0000060: 6967 6874 0000 5443 4f4e 0000 0006 0000 ight..TCON......
In contrast, in the following file there is no padding so there is no semicolon.
0000030: 6e74 7279 5441 4c42 0000 000d 0000 0054 ntryTALB.......T
0000040: 6861 7427 7320 5269 6768 7454 434f 4e00 hat's RightTCON.
Hmm.
Both examples are correctly formatted ID3v2 frames. The former is a 15 character frame consisting of 1 encoding character and 14 text characters "That's Right" + 2 x NUL. Whereas the latter is a 13 character frame consisting of 1 encoding character and 12 text characters "That's Right" (no nulls). Both frames use the ISO-8859-1 LATIN encoding, and indeed the NUL is a perfectly valid (albeit non displayable) character in that encoding.
So I think that both your tags are legally within specifications.
And I think the problem is that MC is wrongly interpreting the ISO-8859-1 LATIN NUL character as a semi colon character. Or perhaps it is interpreting the NUL as a break between two (empty) sub strings and inserting semi colons as a separator between those two empty subs strings (??) In either case, I think this is a bug in MC's ID3v2 parser, which definitely needs to be fixed..
-
It does interpret the NUL as a separator between two strings, as ID3v2.4 specifies.
However, I don't think empty strings are technically allowed here, so it probably shouldn't.
I do however think the extra null is not 100% up to spec, it doesn't seem to allow arbitrary padding with null chars according to the spec.
-
I do however think the extra null is not 100% up to spec, it doesn't seem to allow arbitrary padding with null chars according to the spec.
Agreed. I don't see any good reason why one would want to pad the string when one could simply write a shorter field. Perhaps the tagging software is trying to avoid rewriting the whole file when a new tag text is shorter than the prior text was ??