I looked through the mapping section of documentation but could not find "Webpage" as in windows explorer--I'd like to use that field for placing a promo URL:
In the meantime, I have been attempting to use %www% for Promo URL. It seems to store multiple values. I can read the field in mp3Tag that was written using AudioShell, but if I attempt to alter in MP3Tag, it no longer shows up in AudioShell in the field where I originally wrote it.
Here's AudioShell results for Episode 109 (data was entered in this app, in URL field, read successfully by MP3Tag as WWW, then I updated mp3tag and the result here in AudioShell is field is blank):
If WWW is not the appropriate field, why did it display the results? Why doesn't it write back properly? I'm a bit baffled, but far from expert on the topic of tagging. Appreciate any help/suggestions from y'all.
Or why doesn't the other program (AudioSHell?) read the field again?
Could you show us a dump of the extended tags dialogue Alt-T of a file with a successfully embedded url?
I just looked at the Windows Explorer properties dialogue for an mp3.
Mine shows only "Artist URL" - and that is shown as WWWArtist in MP3tag.
Data in WWW isn't shown in the WE.
Audioshell writes this field like this:
Mp3Tag writes this field like this:
As soon as Mp3Tag writes anything to the file this field is also changed and Audioshell does not read it anymore. If you write this field with Audioshell again an additional url-field is written to the file and so on.
According to the standard (4.3.2) it is a "User defined URL link frame":
Audioshell also knows "Additional Tags" for Urls and with these the compability-problem does not seem to happen, i.e. "WWWAUDIOFILE" in Mp3Tag and "Audio file information webpage" in Audioshell.
The problem is probably a different character encoding.
Audioshell seems to save ISO-8859-1. By default, MP3Tag uses UTF-16.
If you switch MP3Tag to ISO-8859-1 for writing, both programs will get along with each other.
The description of the standard for this frame says
"The URL is always encoded with ISO-8859-1."
Poster & Ohrenkino, thank you! The behavior is as you've stated. If I change the writing to ISO-8859-1, this seems to solve the problem. I did do an Alt-t (nice tip) prior and it showed multiple entries of "WWW" (didn't screen shot it), now it appears fine (after the change). I have clean-up to do and perhaps my strategy moving forward is to NOT use WWW, but one of the other fields that is perhaps more appropriate (like wwwcommercialinfo or podcasturl). I appreciate how quickly you both responded.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.