Helium 13 - Beta 2 - Build 13.0.14789.0
Audio Files an DB are on the local machine
Local Account that execute Helium 13 has administrator rights
1) Open Music Explorer.
2) Select Releasetype "Maxi/Single"
3) Take a look at the small circle icon at the left buttom. It should be a "M".
4) Press "Strg" + "E" to open the tag editor.
5) Take a look at the "Basic" register on the field "Releasetype". You can see "Not defined".
6) Check all other register but no entry "Maxi / Single" detected.
7) Do the same with three other entrys and it's all the same.
I make screenshots of this and attach them as files.
If anyone would like to test the new version with the above improvements, please open a support ticket at: http://support.imploded.com.
If you follow the discussion above you can see that release type, genre and publisher is stored differently (not using the "standard tag-frames") in MP3Tag.
Genre is stored in ID3v1 format as a byte instead of free text, publisher is stored as an iTunes specific "free frame" and the same with release type.
Not sure what you mean with that files are not touched, fields are properly updated during tagging, it's just that some of them cannot be read properly when changed with MP3Tag.
The solution in Helium 13 will be that we have extended m4a tags to support genre in ID3v1 format, publisher in the iTunes format.
For release type we will create a mapper where end-users will be able to configure which specific free-text that should be mapped to a specific Helium release type.
This will allow any combination of mappings and it will also apply to MP3 files (ID3v2 tags)
Earlier versions of Helium was not able to handle these tag fields, at least not for the files Stephan shared.
I reported this case still under Helium 12 that M4A-files are not touched under Helium 12 and now Helium 13 at all. I reported this case but so far it was ignored. If you tag a new and untagged m4a file in a fresh new database the helium database shows full tagging. But under windows explorer you can see that the files are fully untouched. No changes in the time stamp. Once updating the database somehow you can see that all tagged fields are empty again. It’s not only release type!
>>I recognized that the same problem also occurs at the tag-fields Genre and Publisher/Label. Perhaps you can take a look at this fields also.
This seems only to be relevant for the M4A files. They work OK for the MP3 files.
I will see if we can extend the read support for the M4A files to be able to read these tags as well.
I uploaded the same two tracks as mp3 file to dropbox.
That would be great, thanks in advance.
If you need it, I can upload the same files also as mp3 files. Please let me know.
Thanks. We will analyse them further to see if we can add read support for that tag format, since they are M4A files the tag format is a bit different.
i added two of this files at the dropbox share.
It seems like MP3Tag is using a different format for the releasetype tag compared to how it is used (since very long) in Helium.
This is most likely the reason why this specific tag cannot be read.
Can you share a file with this release type?
Possibly we can add read-support for it for a future Helium release.
i recorded same vinyl tracks at the weekend and tag them with mp3tag before i imported them to Helium.
After the import, i take a look of them at Helium and see the same issue with the releasetype as mentioned before.
So I look again at the tags with mp3tag and also take a look at the database at the sql server management studio. In mp3tag you can see the used RELEASETYPE tag, but this tag isn't given to the database and so also not in Helium. Now I ask myself if the tag RELEASETYPE is not an offical tag.
I make screenshot of this and attach them to this reply.
Thanks for the files Stephan.
I have analysed the files tags via:
-Properties in Helium 13
-Properties in Helium 11
And the simply does not contain and release type tag-frames (rtyp) and therefore they are not shown.
I cannot answer why they were shown initially, it is unfortunatley nothing I can reproduce.
I consider the code in Helium 13 to be working as expected according to the above tests, therefore I will close this bug.
If you can identify a case where the release types are added and then removed without purpose, please open a new ticket.
it seems that number one was not uploaded, so i try it again
And last but not least number three