When writing DSF file with existing metadata chunk we dont rewrite DSDChunk filesize to reflect changes due to new metadata chunk
Issue #225
resolved
I have a problem when I modify (enlarge) ID3V2(3-4) tags in DSF files with text which is larger than the currently available padding in the tag. Although the tag can be re-read with JAudioTagger as well as Windows Explorer Audio Properties (Which seems to me to be a DBPowerAmp extension of the Windows explorer) and also JRiver where when I look at the Tag dump it all seems Ok . But MP3Tag v2.8a displays (!BAD ID3v2) which probably means that there is something not very kosher. When I change something in the tag using the jRiver Tag editor the Tag is apparently re-written correctly again and MP3Tag can display and modify the tag again. Note that MP3Tag is not able to write to the tag when it is in that bad state. Note this problem apparently does not occur in the FLAC OGG tags. And even in an MP3 file the problem did not occur. I can provide a broken file but it as it is DSD it is rather huge 52MB
Comments (21)
-
repo owner
-
I have dropped off the DSD file on WeTransfer, You can pick it up. It still is 52 Mbyte but is one of the smallest DSD files I could find Download link https://wetransfer.com/downloads/1bf8302e61b3de3540787153753e1f9b20171013204204/acceb9d8e31854c98ea839fb8605af4620171013204204/11382a
1 bestand 02 Recitativo Ich habe genug.dsf
-
I send you also the DSD file prior to the Artist, AlbumArtist, tag field modification. Maybe it can help to track the problem? The We Transfer URL is Download link https://wetransfer.com/downloads/adde30d05949379d52a649d7ec9a982820171014055545/c422444fbed7b9ba712065d9876f0ab820171014055545/480964
It will stay alive for 7 days
-
repo owner
Hi thanks I have files, interestingly both files are same size although I can see diffence at end, but I cant see difference in metadata that you mentioned, was the metadata actually modified ?
-
Actually Yes but in the case of the original I modified it afterwards manually with MP3Tag.
I have re-send both files. The original one, this time is the one that was used as source (so before the modification by JAudioTagger) and the modified one is the one after the modification.
So now you have the original one the one modified by the (sublime and very handy, thanks for that) JAudioTagger and the one (the previous original file downloaded) modified by MP3Tag with the same modifications.
I hope it can be helpful.
I would try to figure it out myself but then I have to have the specification of the ID3v24 DSF file layout (which I do not have). I guess that something is not absolutely conform the spec with the padding (just a wild guess, as I stepped through the complete process and could not find something wrong as is with the handling in itself)
Download link
2 bestanden
02 Modified Recitativo Ich habe genug.dsf
02 Original Recitativo Ich habe genug.dsf
Verzonden: zaterdag 14 oktober 2017 11:29 Aan: percychris1@gmail.com Onderwerp: Re: [Bitbucket] Issue
#225: MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag (ijabz/jaudiotagger)https://avatar-cdn.atlassian.com/adc85b2c054f3eb102da8eb68545dca4?s=32&ts=1507973066
IJabz commented on issue
#225:https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag
Hi thanks I have files, interestingly both files are same size although I can see diffence at end, but I cant see difference in metadata that you mentioned, was the metadata actually modified ?
https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a View this issue or add a comment by replying to this email.
https://bitbucket.org/api/1.0/repositories/ijabz/jaudiotagger/issue/225/unwatch/percychris/2b12c80d9ebbb3a17955f53c80776ea116ebd8d5/ Unwatch this issue to stop receiving email updates.
-
repo owner
Ive downloaded and still the metadata is the same which is different to my understanding that jaudiotagger has modified the metadata, it doesn't seem the files are any different the ones you originally sent. Can you recheck and point out what metadata change has been made
-
Note: Sometimes when you look at a field (depending on your viewer you will only see the first of the zero delimited strings
In The “02 Modified Recitativo Ich habe genug.dsf” the Artists tag was changed from “Sigiswald Kuijken” to “Sigiswald Kuijken|La Petite Bande|Elisabeth Hermans|Petra Noskaiova|Christoph Genz|Jan Van der Crabben” Not that the | in the representation are multiple zero terminated artists (In MP#Tag this separator is “\”). They were added as by multiple tag.addField(FieldKey.ARTIST, artistName). In FLAC this results in multiple Artists tag fields but in ID3V24 this is a single TPE1 tag. Also the, with MP3Tag modified Artists field contains the same multiple zero separated artists names. The AlbumArtist tag in the JAudioTagger modiefied file contains (in this case) the same data as the Artists Tag. In the original file this was “La Petite Bande\Elisabeth Hermans\Petra Noskaiova\Christoph Genz\Jan Van der Crabben” Note that the “Sigiswald Kuijken” was added in the modified file. Also, as mentioned previously, when I change something with the JRiver Mediacenter 23 integrated tag editor, everything is back OK for MP3Tag.
-
repo owner
ah okay, sorry I can see the different metadata now, thanks
-
I walked a bit though loading of the loading of the tag of both, the MP3Tag and the JAudioTagger modified TPE1 ID3V24 artist tag, and noted that the size of the frame is different (1103 for JaudioTagger and 104 for MP2Tag). Remember that the tag data contains multiple zero terminated strings. In the with MP3Tag modified file the last string contained in the tag is also zero terminated which is NOT the case in the JAudioTagger modified file.
-
repo owner
The http://id3.org/id3v2.4.0-frames D3v24 4.2 section spec says 'There may only be one text information frame of its kind in an tag. All text information frames supports multiple strings, stored as a null separated list, where null is represented by the termination code for the character encoding' I read that as NOT expecting the last string to be null terminated as non of the preceding strings are null terminated they are just null separated, and note they are not null terminated in ID3v23
-
Yes, and even if I add the termination zero (where both MP3Tag and JAudioTagger) tag body length are 104 the problem persists. So maybe just adding the terminating zero is not the real problem. For the moment I am clueless
-
I have asked Mr. Florian, the developer of MP3Tag, what exactly was wrong with the tags. And after analysis he came to the conclusion that when the Tags are extended, the total file size in the DSD file header isn’t updated. Maybe this can be fixed in a further version. Many thanks in advance.
-
I have modified the org.jaudiotagger.audio.dsf.DsfFileWriter file so that it adapts the dsd header file length field correctly in case the tag size is grown. Now MP3Tag accepts the modified file. I have dropped the modified java file in a shared folder on my dropbox. I added a private inner class to return the necessary data back to the caller. this can probably be made neater with local variables in the final version (if concurrency allows it) It is just a temporary quick and dirty fix for myself to make it work.
Link to the modified file. https://www.dropbox.com/sh/xsbqnvrsap0jr59/AADAd1Cz9p_MQmWaFd1Ba3-Va?dl=0
-
repo owner
Thankyou for this, looking at it now.
-
You’re more than welcome. It is me that has to thank you for making the library available.
I used a nested class and not local variables of the class because the data exchanged is only local between the two object methods.
Verzonden: maandag 6 november 2017 10:18 Aan: percychris1@gmail.com Onderwerp: Re: [Bitbucket] Issue
#225: MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag (ijabz/jaudiotagger)https://avatar-cdn.atlassian.com/adc85b2c054f3eb102da8eb68545dca4?s=32&ts=1509959841
IJabz commented on issue
#225:https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag
Thankyou for this, looking at it now.
https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a View this issue or add a comment by replying to this email.
https://bitbucket.org/api/1.0/repositories/ijabz/jaudiotagger/issue/225/unwatch/percychris/2b12c80d9ebbb3a17955f53c80776ea116ebd8d5/ Unwatch this issue to stop receiving email updates.
-
repo owner
Hi, okay i understand the error properly now the DSDfileSize value is not correctly rewritten when the size of the ID3 tag changes, I think there is some problems with your fix it is misunderstanding that the existingTagSize is the size of the new tag not the old tag, and it doesnt attempt to handle when tag size shrinks.
But I will work on an alternative fix now, and should be available later today if you dont mind testing it out.
-
No The nested class keeps the orginal tag size (prior to converting the new tags) and then also keeps the new tag size. It then handles the increase. But you are right in that I do not consider the shrink in itself although the file size is decreased (due to a negative figure returned by the nested class) if the tag size decreases.
No problem. I sure will. I will check it out this later today. Thanks again.
Verzonden: maandag 6 november 2017 11:28 Aan: percychris1@gmail.com Onderwerp: Re: [Bitbucket] Issue
#225: MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag (ijabz/jaudiotagger)https://avatar-cdn.atlassian.com/adc85b2c054f3eb102da8eb68545dca4?s=32&ts=1509959841
IJabz commented on issue
#225:https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a MP3Tag reports (!BAD ID3v2) after extending a DSD ID3v24 tag
Hi, okay i understand the error properly now the DSDfileSize value is not correctly rewritten when the size of the ID3 tag changes, I think there is some problems with your fix it is misunderstanding that the existingTagSize is the size of the new tag not the old tag, and it doesnt attempt to handle when tag size shrinks.
But I will work on an alternative fix now, and should be available later today if you dont mind testing it out.
https://bitbucket.org/ijabz/jaudiotagger/issues/225/mp3tag-reports-bad-id3v2-after-extending-a View this issue or add a comment by replying to this email.
https://bitbucket.org/api/1.0/repositories/ijabz/jaudiotagger/issue/225/unwatch/percychris/2b12c80d9ebbb3a17955f53c80776ea116ebd8d5/ Unwatch this issue to stop receiving email updates.
-
repo owner
- changed title to When writing DSF file with existing metadata chunk we dont rewrite DSDChunk filesize to reflect chnages due to new metadata chunk
Modified title to better describe the issue
-
repo owner
- changed title to When writing DSF file with existing metadata chunk we dont rewrite DSDChunk filesize to reflect changes due to new metadata chunk
-
repo owner
I believe I have fixed it and checked in the code
-
repo owner
- changed status to resolved
Done
- Log in to comment
Okay, can you upload it somewhere and make available to support at jthink dot net please so i can take a look