Print

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

[aussie1]

When editing file properties, large comments stored in the ID3v2 tag are cometimes truncated. I can find the pattern yet.

S

[Sauzee]

Yes I have that problem as well.  MC seems to overwrite the ID3 2 tag with the ID3 1 tag.  

I'm afraid I don't know what the solution is.  It seems to happen with all builds of MC.

[KingSparta]

I just checked my MP3's and they are fine

are you talking about MP3's

[aussie1]

yes, I'm talking about MP3s.  It was a problem in 9.0. Originally, I thought it was fixed in 9.1.

In 9.0 the pattern was simple:
1. import a file that has v1 comment tag empty and v2 comment tag full.
2. edit any file property and save
3. the v1 tag now has the first 28 characters of the v2 tag.  v2 tag is fine
4. edit any property and save
5. the v1 tag overwrites the v2 tag.  (They both now have only the first 28 characters of the text.


I haven't tested the pattern in 9.1.  I think it is partially fixed.  But there is still a problem. Comments have been truncated on 150 of the albums I just edited. Strange thing is the the comments are fine in some of the other albums I edited. So, I'm not sure how to reproduce.


Media Center Registered 9.1.226 -- C:\Program Files\J River\Media Center\

Microsoft Windows 2000  Workstation 5.0 Service Pack 4 (Build 2195)
Intel Pentium III 996 MHz MMX / Memory: Total - 523 MB, Free - 230 MB

Internet Explorer: 5.50.4134.0600 / ComCtl32.dll: 5.81 / Shlwapi.dll: 5.50.4134.600 / Shell32.dll: 5.00.3700.6705 / wnaspi32.dll: N/A
Ripping /   Drive E:   Copy mode:ModeBurstBigBuffer   CD Type:Auto   Read speed:Max
 Drive F:   Copy mode:ModeBurstBigBuffer   CD Type:Auto   Read speed:Max
 Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: No /  Copy volume: 32767
 Eject after ripping: Yes /  Play sound after ripping: Yes  Soundfile:   chord.wav

Burning /  Drive E: LITE-ON  LTR-52246S         Addr: 1:0:0  Speed:52  MaxSpeed:52  BurnProof:Yes
 Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: No
 Use playback settings: No /  Normalization: None

[Sauzee]

After another look I think that 9.1 is just displaying the the id3 v1 tag - it doesn't appear to be overwriting it.
If you delete the id3 v1 comment the v2 full comment appears.

However...., if you then edit the tag again it might go back to displaying a v1 comment field.

Just tried it.  It's now overwriting the id3 v2 comment field with the v1 comment.  Oh dear ?

[Nikolay]

aussie1,

I tried to reproduce the problem but to no avail. Are your settings for mp3 tagging configured correctly?

Nikolay

[aussie1]

Nikolay,

9.0.180 and 9.1.226 (I haven't tried later versions) behave differently.

For 9.0.180, I am quite sure that the behavior I described above always occurs.


For 9.1.226, the pattern seems to be different. If the v1 tag starts as blank, tagging seems to work ok (but I haven't tested all possibilities)

However, try this:

Using a different tag editor (ID3-TagIT or Tag&Rename), place large text comments in the V2 tag. Then tag the v1 comment tag with something random such as ("abc"). Now import the file into MC. If I look at the format properties for the file, the V1 tag has "abc" and the v2 tag has <too large to display>. Fine.   Any views that show the comment field display "abc".  (I think you should change this to default to the v2 tag rather than the v1 tag.)

Now edit a file property (change the artist, for example). Look at the format properties and now both the v1 and v2 comment fields contain "abc".  The large comment that was contained in the v2 tag is lost.

QED.

If there is an MP3 tagging setting that I am missing, let me know, but I've studied all of the menus quite closely.



S

[aussie1]

Whoops,

I meant to address the last message to Nicolay.  Apologies all around. And thanks for listening.

S

[jfmus]

I just discovered this problem myself. Thought I was losing my mind. Glad to know I'm not the only one. I solved my issue for the moment by just deleting all the v1 comment fields.

jfmus

[Nikolay]

aussie1,

I'm still unable to reproduce the problem. The only way I could make MC to save v1 tags into v2 is by checking option "Ignore ID3v2 tags during analysis" which is located in configuration window for MP3 plug-in.

I did exactly what you said. I even downloaded Tag&Rename. Still, no luck

Nikolay

[KingSparta]

aussie1

I wonder if the orginal mp3's were ripped with Musicmatch

if so that maybe another known problem, any ideas?

[aussie1]

Nikolay,

Are others seeing this behavior?

Odd! I tried it again and I still have the problem. Perhaps it is a settings issue:

For the MP3 input plug-in, my settings are:
ID3V1 Mode: Save (create if necessary)
ID3V2 Mode: Save (create if necessary)
Ignore ID3V2 tags during analysis is not checked

My General options are:
Update tags when file info changes

All custom fields are set to store in tags when possible.


The General Pattern is:
If the V1 comment field has data prior to importing, then the V2 comment tag is overwritten when file properties are changed.

If the V1 comment field is empty prior to importing, then all seems to work ok.


In all scenarios below, the V2 tag starts with a large comment prior to importing the file. Also, the V2 mode is set to save.

Case 1: V1Mode = don't save; V1 Comment tag = empty on import:
Comment displayed in file properties window is the V2 tag
No problems editing file properties here

Case 2: V1Mode = don't save; V1 Comment tag = has data on import:
Comment displayed in file properties window is the V1 tag
Truncating comment problem occurs

Case 3: V1Mode = save; V1 Comment tag = empty on import:
Comment displayed in file properties window is the V2 tag
As I would expect, the first time I edit a property, the beginning of the v2 comment is written in the V1 tag.
If I edit another file property, everything is fine.
If I now delete this file from the library and reimport, it behaves as Case 4.

Case 4: V1Mode = save; V1 Comment tag = has data on import:
Comment displayed in file properties window is the V1 tag
Truncating comment problem occurs

Conclusion
My guess is that when you read a file on import, you check for data in the V1 comment field first. If it contains data, then you populate your database with that data. If the V1 tag is empty, then you read the V2 tag and populate your database with the data that is contained there. The problem is that the V1 tag is limited to 28 (or so) characters. I think the order should be reversed. You should give the V2 tag priority when populating your database on import.

I'd argue that all v2 fields should be given priority over v1 fields during import, but I haven't tested anything other than the comment field.

Are there other settings that I am missing?

If you still can't reproduce this, you can e-mail me separtely, I'll give you my phone number and we can discuss. I still stand behind my assertion that this is a bug that should be solved.

I am still using 9.1.226. I will download one of the newer betas soon.

S


Media Center Registered 9.1.226 -- C:\Program Files\J River\Media Center\

Microsoft Windows 2000  Workstation 5.0 Service Pack 4 (Build 2195)
Intel Pentium III 996 MHz MMX / Memory: Total - 523 MB, Free - 125 MB

Internet Explorer: 5.50.4134.0600 / ComCtl32.dll: 5.81 / Shlwapi.dll: 5.50.4134.600 / Shell32.dll: 5.00.3700.6705 / wnaspi32.dll: N/A
Ripping /   Drive E:   Copy mode:ModeBurstBigBuffer   CD Type:Auto   Read speed:Max
 Drive F:   Copy mode:ModeBurstBigBuffer   CD Type:Auto   Read speed:Max
 Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: No /  Copy volume: 32767
 Eject after ripping: Yes /  Play sound after ripping: Yes  Soundfile:   chord.wav

Burning /  Drive E: LITE-ON  LTR-52246S         Addr: 1:0:0  Speed:52  MaxSpeed:52  BurnProof:Yes
 Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: No
 Use playback settings: No /  Normalization: None

[Nikolay]

I'd argue that all v2 fields should be given priority over v1 fields during import.

That's exactly what we do, but if we fail to read v2 tags we will try reading v1 tags.

We will do more testing.

Thanks for your help,
Nikolay

[aussie1]

King Sparta,

The original MP3s were ripped by MC using the MP3 Encoder.

There were tagged using Tag&Rename. (To download cover art and album description from AllMusic).

Some of the files were updated with ID3TagIt because I store data in the publisher tag and this field is not supported by MC.

It is possible that one of those programs is causing the problem. Lets test that:

Test 1
Rip a file using MC. Using MC, type a long comment into the comment field. Save the change. Delete the file from the database and reimport.
Result
Hmm.  In this case MC seems to handle the file just fine. But I haven&#8217;t done a thorough test.


Test 2
Rip a file using MC. Using Tag&Rename, import the tag information from AllMusic and save. Import the changed file into MC.
Result
The file behaves as described in my previous post. Comment truncates.

Test #3
Rip a file using MC. Using ID3TagIt 2.3.4, edit the comment field. Import the changed file into MC.
Result
Hmm. In this case MC seems to handle the file just fine. But I haven&#8217;t done a thorough test.

Conclusion
Tag&Rename and MC seem to have a conflict on the tags.  Why? At this point, we've reached the limit of my ability to test. Also, why couldn&#8217;t Nikolay reproduce?

S

[aussie1]

Based on Nickolay's latest response, my next guess is that it is a failure to read Tag&Rename's comment tag.

[aussie1]

Another possiblity:

I've tried adding the album decription using MC by doing a simple cut and paste into the comment file property.

If the description is only one paragraph, it works with no problem. However, if the description contains more than one paragraph (separated by what I assume is the paragraph character), MC only accepts the first paragraph.

So perhaps the import problem is caused when you read a comment tag that contains either more than one paragraph, or some other special character.

S

[Nikolay]

Hurray!!!! We found the bug. It will be fixed in the next build. The bug would only come out if comment field was over 1028 characters.

Thanks for your help,
Nikolay

[KingSparta]

The bug would only come out if comment field was over 1028 characters.

allot of chrs for a comment field

[aussie1]

You guys rock!