Help - Search - Members - Calendar
Full Version: iTunes tags gone after Replaygain
Hydrogenaudio Forums > Hosted Forums > foobar2000 > General - (fb2k)
Doktor_Lorenz
Many thanks to the Nero team for releasing neroaacenc, it is much appreciated and i'm sure many more people will be thankful for your hard work [even if it took me a little while to get the hang of using it thru eac].

I do have one question, I am currently encoding my m4a file using eac and atomic parsley for the tagging part [for itunes this is important for my dad not for me] but why is it when I replaygain my files using foobar 0.9 that my tags that were fine in itunes before then just defaults to the filename.

torok
Yea, same deal here:

http://www.hydrogenaudio.org/forums/index....showtopic=44454
Doktor_Lorenz
QUOTE(torok @ May 25 2006, 23:51) *


Actually I'm not too bothered about Foobar not being able to read the tags, but what i am bothered about is the fact that when I apply replaygain thru foobar that it totally destroys the tag that atomic parsley applied in the first place so I could use it thru iTunes.
Me and my dad both have iPods where as he uses and insists on using iTunes i prefer using foobar to upload to my nano, the problem lie in that I want to rip both dads cd and mine to at least iTunes standard so dad can pick and chose what he wants in his ipod using itunes [he loves the fact you can apply album art as well, prolly bragging rights etc etc]
Ideally i'd like to be able to rip as i do now but find a way of applying replaygain without totally destroying the tags that atomic parsley creates.

thanks for quick replay anyway
TrNSZ
Simply stated, Atomic Parsley is corrupting Nero tags, not to mention it does not (or at least did not) even work correctly with all the Apple tags in all cases. The source is available, and it's a mess, and some of the comments are very telling. It isn't even to the specification, and rather than fixing the problems, there are many hacks. The bug list is very telling. The author has a beef against foobar2000 and Nero Digitial's tagging specification and older versions seemed to corrupt the Nero tags purposely. Maybe it was a "mistake", but the code is out for everyone to examine, being GPL. All in all, this behavior is very unprofessional if nothing else.

I'd stay the hell away from Atomic Parsley. The author has this childish game he's playing crusading against the Nero tagging specifications even though they can easily co-exist with Apple's scheme. The worst case scenario is some metadata might be duplicated. I guess the Atomic Parsley author thinks that per-chapter metadata and other advantages are "so out-o-spec" while the "specs" he follows are simply reverse engineered as well.

I recommend everyone read the previously referenced post. NeroAACtag is literally right around the corner, and you can use foobar2000 for tagging from the command-line if you want as well, and it doesn't write corrupted or invalid tags.

Everyone should avoid this nonsense like the plauge.
MelOFlow
I read the buglist the day the new version of AP came out. Unless I am incapable of deciphering plain english, I am unconcerned by those minor issues. The only one that I may come up against is the MAXPATHLEN issue for win32. What bugs are you referring to that I should watch for?

As for whatever tags you say AP writes that are corrupted or invalid, I haven't seen it. I have used it extensively in both a wrapped form and on the command line. I find the ability to set the great abundance of tags better than anything out there. The only problem is that there are SO many options. The 3gp options are especially copious, but I only glanced at them. But I suppose that provides for increased flexibility, so I can't complain too much. Every tag I set gets picked up by iTunes, which ones are you talking about? Can you provide an example command to create such an invalid tag?

Nero found problems everywhere else except in their own house. It's kind of hard to argue with "You can't create your own atoms" and "Use this mechanism to extend functionality" and Nero doesn't do it. So your problem was that it was brought to their attention that they weren't compliant? Since Nero people didn't dispute that it used libmp4v2 from mpeg4ip, that must be what they use. Even mp4tags which uses libmp4v2 picks up the right info, so I doubt its an AtomicParsley issue.

If you actually used libmp4v2 with any frequency, you would find that libmp4v2 does have a few issues of its own - issues that don't affect AP. I'm not saying AP is perfect - it has different issues, but if you think that NO software has hacks... you are on the wrong OS. Your "hack" may be someone's "accommodation". For example, you either include things by explicitly listing them, or allow everything and specifically exclude things. Its a matter of perspective - perhaps you are lacking it. There is 1 big hack that I see in the code, but since it writes files that everything I have picks up fine, I'll live with it. But here is someone else take on libmp4v2 - perhaps you missed it as well:

http://forum.doom9.org/showthread.php?p=830119#post830119

I believe the problem of foobar2000 not picking up tags lies in foobar2000 itself. As an example I tagged a number of files with both foobar2000 & AP. Foobar didn't pick up the tags that were modified by AP (or iTunes) - but as soon as I erased the 'tags' atom with an enema, Foobar did pick them up. The lesson here is that if you have 2 tagging systems, which one takes precedence? If Nero's tagging only writes the encoder tag for both tagging systems, and then AP writes everything else (valid tags mind you, but only iTunes-style tags), then Foobar has to pick a tagging scheme. Seems it leans towards its own implementation, rather than the one everything else uses. Go try it yourself - please post your findings and where the blame belongs.

As an example, use this on a file encoded with the free Nero encoder (to be sure it has the 'tags' atom in question; or alternatively with a file tagged by foobar2000):
CODE
AP.exe file.m4a --artist "The Artist" --title "A Title" --comment "A Comment"

then try
CODE
AP.exe file.m4a --artist "The Artist" --title "A Title" --comment "A Comment" --foobar2000enema

iTunes & my iPod can get the right metadata - does foobar2000? Yes, but only with the 2nd one. Since I'm not about to give up my iPod, iTunes, I know which side of the fence I'm on - the side of iTunes-style metadata. Perhaps if you directed some of that venom towards figuring out WHY it was happening instead of scrutinizing every line of code, you would have too. BTW, the first enema switch was there before AP was even cross platform - and probably before foobar2000 was even on the AP radar. To be honest, it makes me smile. Must be my liberal upbringing.

As for redundancy of tags - lots of users are trying to make their files smaller & smaller. Say they want to embed artwork. 400k for 4 pix is a whole lot less than 800k when doubled. Over a dozen files, that amounts to an extra song. That's a penalty that doesn't exist yet, but will soon.
TrNSZ
AP corrupts Nero tagging scheme, and actually nulls out their tags, so they appear to exist but contain no data. As far as I am aware foobar2000 gives the Nero-style tags precedence where they exist. This kind of nonsense seemed specifically directed at breaking interoptability with foobar2000 and Nero products. Such is childish, along with some of the other comments to be found in the source code. Unless Peter or someone else can correct me or be more specific here, this is the crux of the issue.

Anyway, as Atomic Parsley is writing corrupt ND tags, but writing otherwise correct Apple tags, this is the reason why iTunes and your iPod work correctly with this program, but not foobar2000. The problem is not foobar2000, but Atomic Parsley.

Also, as far as I know, there is nothing non-compliant with the Nero scheme. It also much more extensible than the Apple scheme. You are calling the kettle black if you think that Apple has not "invented" their tagging standard as well, which also remains unpublished.

PS - The reason why AP works with the "fb2k enema" is because instead of corrupting the ND tags, it just removes them, and foobar2000 falls back on the Apple-style tags. The whole "foobar2000 enema" feature, whether it gives you chuckles or not is totally not needed. It's there because the author has a point he's trying to make, and without merit.

Also, there is not a "side of the fence". You are using software that is full of bugs. There is no reason why the metadata cannot co-exist. It doesn't work in this case only because you are using a crappy program.

NeroAACtag will fix all this mess.
spoon
>Atomic Parsley is writing corrupt ND tags, but writing otherwise correct Apple tags,

Can you clarify this, all m4a ID Tags are standardized around iTunes (or the older Quicktime) tagging. What are Nero Digital tags? (not talking unique atoms here, but standard tags), if ND writes an artist tag, iTunes should read it?
MelOFlow
You've seen the AP code - what line number nulls out the tags? It doesn't even touch them - it skips over them. When write out time comes, all it does is copy the entire 'tags' atom. You clearly didn't look at the code very well - and yet you found bugs all over the place. I doubt your abilities to spot bugs then.

Work it from a different angle - have you looked at the file in a hex editor? search for 'tags' on a before & after. Your thoughts on the identical contents? Still sticking to it being NULLed out?

The reason why foobar2000's tagging scheme is non-compliant was already given. That you don't want to understand it is another issue. Say AP wanted to use 'tags' for something. What if everybody decided to start with their own atoms? What use is a 'standard' if everyone is adding their own crud. ISO stands for something you know.

edit: in fact, when it comes to removing atoms, AP doesn't even null out the whole tag - all it NULLs out is the atom name and the order it comes in. The contents of an atom aren't read in at all unless final writeout time comes (when their are copied unaltered), or for non-descructive reading. You may want to refer to the 'APar_EliminateAtom' function for verification. Anything you care to get *right*?
TrNSZ
QUOTE(MelOFlow @ May 26 2006, 10:47) *
The reason why foobar2000's tagging scheme is non-compliant was already given. That you don't want to understand it is another issue. Say AP wanted to use 'tags' for something. What if everybody decided to start with their own atoms? What use is a 'standard' if everyone is adding their own crud. ISO stands for something you know.
I'll refute the rest later, but do you care to explain how Apple's own "invented" atoms are any more or less valid than ones created by another company?
spoon
>Apple's own "invented" atoms are any more or less valid than ones created by another company?

They sort of got there first (2 years ago) and they are arguably creating more m4a tagged files than anyone else, what good is two standards?
TrNSZ
QUOTE(spoon @ May 26 2006, 10:43) *

>Atomic Parsley is writing corrupt ND tags, but writing otherwise correct Apple tags,
Can you clarify this, all m4a ID Tags are standardized around iTunes (or the older Quicktime) tagging. What are Nero Digital tags? (not talking unique atoms here, but standard tags), if ND writes an artist tag, iTunes should read it?

Nero tagging is extended to allow per-chapter metadata and native replaygain storage.

Anyway, MelOFlow:

When it comes to AP, there is atom tags that has a null'ed out field count, and foobar2000 is going to look for tags in the ND then iTunes order. It sees the ND tags, and goes to parse them, but then finds no fields are present, and thinks that is has completed reading the tag. AP seems to sabatage the ND data in this way. It doesn't actually null out the actual metadata itself.

I've tested a new version of foobar2000 that includes a new tag reader that has a workaround for tags that are corrupted in this way. Is this a bug, or is it sabotage? Who knows.

Anyway, you may claim that I fail at finding bugs, but you fail at reading sources.

QUOTE(spoon @ May 26 2006, 11:07) *
>Apple's own "invented" atoms are any more or less valid than ones created by another company?

They sort of got there first (2 years ago) and they are arguably creating more m4a tagged files than anyone else, what good is two standards?
I agree, but the Nero standard has functionality sorely missing in the Apple specification, such as the ability to work with metadata on a per-chapter level. Neither company has published specifications yet, either. I say that whoever publishes first is the real "winner" here.

Not to mention the fact that if you don't include ND tags at all, foobar2000 works just fine with them. If you break the ND tag, foobar2000 is going to parse the broken tag, and give you broken data. iTunes is going to read the Apple tags regardless. The Nero tools and foobar2000 write both to the file anyway. Atomic Parsley decides to break the ND tags. This MelOFlow guy claims it does not, which is false. Something tells me this might be the Atomic Parsley author in disguise. Same attitude, anyway, and same senseless crusade against Nero.
MelOFlow
trnsz:

You are incorrect. Please provide a line number if you can. Or look at it in a hex editor. A dodgeball master.... MASTER!!! Just look in a hex editor - you will see they are still there. Man, that's some hardcore denial!

spoon:
There are at least 5 known ways of tagging ISO base Media files:

Quicktime style metadata "moov.udta.XXXX" in utf8/utf16 with language code
iTunes-style metadata "moov.udta.meta.ilst.XXXX" utf8, 'data' child carries the tag
3GPP-style assets "moov.udta.XXXX" very much like QT tags, but a differntly named set
ID32-style tags that were recently added; aims to incorporate id3v2.x tags
f2k-style tags - "moov.udta.tags" which you have to to ask Nero about since they are such staunch defenders. Looks to replicate iTunes-style tags but more string-like
[jpeg2000 files may do exif metadata]
[mpeg21]

Only foobar2000 (and the upcoming neroAActags presumably) will be able to use the new tagging scheme. Both do not incorporate their own taggers, but instead use libmp4v2 to write tags. Lets not kid ourselves, they aren't that hard to figure out. Only they will be able to read them at first. They must be having a "meeting of the minds". What probably doesn't help is that libmp4v2 doesn't have support for the uuid mechanism (at least I don't remember seeing it) that SHOULD be used. That might have influenced why they went another way.
menno
QUOTE(MelOFlow @ May 26 2006, 17:21) *

Both do not incorporate their own taggers, but instead use libmp4v2 to write tags.


False
TrNSZ
QUOTE(MelOFlow @ May 26 2006, 11:21) *
You are incorrect. Please provide a line number if you can. Or look at it in a hex editor. A dodgeball master.... MASTER!!! Just look in a hex editor - you will see they are still there. Man, that's some hardcore denial!

Just because you decide to say something doesn't make it true. You can look at the file posted by torok HERE. This file was molested by AP. Too bad I don't know what previous version it was! The best thing about it is that you can't claim I manipulated it, since I had nothing to do with posting it. =)

Here is the hex dump, totally unabridged so you can't say I modified it. I only skipped padding:
CODE

0000000: 0000 001c 6674 7970 6d70 3432 0000 0000 ....ftypmp42....
0000010: 6d70 3432 6973 6f6d 6e64 6961 0000 0fe6 mp42isomndia....
0000020: 6d6f 6f76 0000 006c 6d76 6864 0000 0000 moov...lmvhd....
0000030: c099 2f6f c099 2f6f 0000 03e8 0000 2d9a ../o../o......-.
0000040: 0001 0000 0100 0000 0000 0000 0000 0000 ................
0000050: 0001 0000 0000 0000 0000 0000 0000 0000 ................
0000060: 0001 0000 0000 0000 0000 0000 0000 0000 ................
0000070: 4000 0000 0000 0000 0000 0000 0000 0000 @...............
0000080: 0000 0000 0000 0000 0000 0000 0000 0002 ................
0000090: 0000 0018 696f 6473 0000 0000 1080 8080 ....iods........
00000a0: 0700 4fff ffff ffff 0000 09e4 7472 616b ..O.........trak
00000b0: 0000 005c 746b 6864 0000 0001 c099 2f6f ...\tkhd....../o
00000c0: c099 2f6f 0000 0001 0000 0000 0000 2d9a ../o..........-.
00000d0: 0000 0000 0000 0000 0000 0000 0100 0000 ................
00000e0: 0001 0000 0000 0000 0000 0000 0000 0000 ................
00000f0: 0001 0000 0000 0000 0000 0000 0000 0000 ................
0000100: 4000 0000 0000 0000 0000 0000 0000 0980 @...............
0000110: 6d64 6961 0000 0020 6d64 6864 0000 0000 mdia... mdhd....
0000120: c099 2f6f c099 2f6f 0000 ac44 0007 ee40 ../o../o...D...@
0000130: 0000 0000 0000 0021 6864 6c72 0000 0000 .......!hdlr....
0000140: 0000 0000 736f 756e 0000 0000 0000 0000 ....soun........
0000150: 0000 0000 0000 0009 376d 696e 6600 0000 ........7minf...
0000160: 1073 6d68 6400 0000 0000 0000 0000 0000 .smhd...........
0000170: 2464 696e 6600 0000 1c64 7265 6600 0000 $dinf....dref...
0000180: 0000 0000 0100 0000 0c75 726c 2000 0000 .........url ...
0000190: 0100 0008 fb73 7462 6c00 0000 6773 7473 .....stbl...gsts
00001a0: 6400 0000 0000 0000 0100 0000 576d 7034 d...........Wmp4
00001b0: 6100 0000 0000 0000 0100 0000 0000 0000 a...............
00001c0: 0000 0200 1000 0000 00ac 4400 0000 0000 ..........D.....
00001d0: 3365 7364 7300 0000 0003 8080 8022 0000 3esds........"..
00001e0: 0004 8080 8014 4015 0000 1400 000e 4000 ......@.......@.
00001f0: 000d 8405 8080 8002 1210 0680 8080 0102 ................
0000200: 0000 0020 7374 7473 0000 0000 0000 0002 ... stts........
0000210: 0000 01fb 0000 0400 0000 0001 0000 0240 ...............@
0000220: 0000 0804 7374 737a 0000 0000 0000 0000 ....stsz........
0000230: 0000 01fc 0000 0011 0000 0014 0000 000a ................
......
0000a20: 0000 000a 0000 0028 7374 7363 0000 0000 .......(stsc....
0000a30: 0000 0002 0000 0001 0000 002c 0000 0001 ...........,....
0000a40: 0000 000c 0000 0018 0000 0001 0000 0040 ...............@
0000a50: 7374 636f 0000 0000 0000 000c 0000 100a stco............
0000a60: 0000 11d3 0000 138b 0000 1543 0000 16fb ...........C....
0000a70: 0000 18b3 0000 1a6b 0000 1c23 0000 1ddb .......k...#....
0000a80: 0000 1f93 0000 214b 0000 2303 0000 0576 ......!K..#....v
0000a90: 7564 7461 0000 00cc 6d65 7461 0000 0000 udta....meta....
0000aa0: 0000 0022 6864 6c72 0000 0000 0000 0000 ..."hdlr........
0000ab0: 6d64 6972 6170 706c 0000 0000 0000 0000 mdirappl........
0000ac0: 0000 0000 009e 696c 7374 0000 0034 a974 ......ilst...4.t
0000ad0: 6f6f 0000 002c 6461 7461 0000 0001 0000 oo...,data......
0000ae0: 0000 4e65 726f 2041 4143 2063 6f64 6563 ..Nero AAC codec
0000af0: 202f 204d 6179 2020 3120 3230 3036 0000 / May 1 2006..
0000b00: 0020 a941 5254 0000 0018 6461 7461 0000 . .ART....data..
0000b10: 0001 0000 0000 4d75 6476 6179 6e65 0000 ......Mudvayne..
0000b20: 0023 a96e 616d 0000 001b 6461 7461 0000 .#.nam....data..
0000b30: 0001 0000 0000 3132 3a39 373a 3234 3a39 ......12:97:24:9
0000b40: 3900 0000 1fa9 616c 6200 0000 1764 6174 9.....alb....dat
0000b50: 6100 0000 0100 0000 004c 2e44 2e20 3530 a........L.D. 50
0000b60: 0000 001a 6368 706c 0100 0000 0000 0000 ....chpl........
0000b70: 0100 0000 0000 0914 4300 0000 0488 7461 ........C.....ta
0000b80: 6773 0000 0480 6d65 7461 0000 0000 0000 gs....meta......
0000b90: 0474 6f6f 6c00 0100 0000 1c4e 6572 6f20 .tool......Nero
0000ba0: 4141 4320 636f 6465 6320 2f20 4d61 7920 AAC codec / May
0000bb0: 2031 2032 3030 3600 0000 1474 7365 6700 1 2006....tseg.
0000bc0: 0000 0c74 7368 6400 0000 0000 000a 0000 ...tshd.........
........
0001000: 000a 0000 13f1 6d64 6174 211b 8340 7deb ......mdat!..@}.


QUOTE
Both do not incorporate their own taggers, but instead use libmp4v2 to write tags. Lets not kid ourselves, they aren't that hard to figure out.
This is blatently false. It is not used to write tags. Care to troll any more?
spoon
> I say that whoever publishes first is the real "winner" here.

No, the winner is who has the greater % of tagged files at any time, Apple are the clear winner right this second.

Here is my take on it:

>iTunes-style metadata "moov.udta.meta.ilst.XXXX" utf8, 'data' child carries the tag

Apple do themselves no favours by not publishing documents, the universe revolves around Apple no?

>3GPP-style assets "moov.udta.XXXX" very much like QT tags, but a

These files are supposed to end .3gp, or .3gp2, no conflics there.

>ID32-style tags that were recently added; aims to incorporate id3v2.x tags

Super idea...<sigh>

>f2k-style tags - "moov.udta.tags" which you have to to ask Nero about

Ok I am hearing you "such as the ability to work with metadata on a per-chapter level.", so you have a file that is tagged by Nero (with both tags, for compatibility), then it is imported into iTunes and the tags altered, now you have a file with two different tags, great!

Why not extend the iTunes tag from within, ie chapter 1 is always the iTunes tag, chapter 2, etc can be anything - new atoms, does not matter.

Too much unilateral action being taken, it is turning into a debacle which will only damage the mp4 perception, or the perception of programs working on those files…
TrNSZ
QUOTE
Ok I am hearing you "such as the ability to work with metadata on a per-chapter level.", so you have a file that is tagged by Nero (with both tags, for compatibility), then it is imported into iTunes and the tags altered, now you have a file with two different tags, great!


In a way, I do agree spoon. However, this is not a necessary shortcoming, but an implementation detail. You can use the ND extensions only if they provide metadata that supercedes that which is stored in the Apple-style tags - that would solve this issue cleanly.

Also, looking at the specifications, it seems you aren't supposed to use moov.udta for storing portable metadata, but Apple does anyway, and so does Nero. The way I read things, this is reserved for user-specific (hence, I read this as application specific and not necessarily portable) metadata.

Who is more right (or wrong) to do so?

Edit: clarified what I was responding to. Anyway, AP poo-poo'ing the ND guys at every moment is still uncalled for, imho.
TrNSZ
CODE
   1736         if (foobar_noncompliant_tags_present) {
   1737                 fprintf(stdout, "\n");
   1738                 fprintf(stdout, "AtomicParsley warning: this file was tagged by foobar2000 with non-compliant tags\n");
   1739                 fprintf(stdout, "\tmore atoms may be present, but foobar2000 writes invalid atom structures.\n");
   1740                 fprintf(stdout, "\n");
   1741         }
not any more "invalid" than Apple/iTunes structures. Let's spread the FUD!

CODE
   2127                                         } else if ( strncmp(atom, "tags", 4) == 0 ) { //oh dear, we have foobar2000's prison-rape tags; thick white gelatinous goo oozes out of this atom
lol.

CODE
   3377         if (percentage_difference < 90 && file_size > 300000) { //only kick in when files are over 300k & 90% of the size
   3378                 fprintf(stderr, "AtomicParsley error: total existing atoms present as larger than filesize. Aborting. %c\n", '\a');
   3379                 exit(1); //a foobar2000 0.9 tagged file would also probably show up here
   3380         }
ORLY? Reality?

CODE
   1722                 } else if (strncmp(thisAtom.AtomicName, "tags", 4) == 0) { // hmmm, I must have missed the 'tags' atom in the ISO spec
   1723                         AtomicInfo FUBAR_tag_atom = APar_FindAtom("moov.udta.tags", false, false, false, true);
   1724                         if (FUBAR_tag_atom.AtomicNumber != 0) {
   1725                                 foobar_noncompliant_tags_present = true;
   1726                         }
   1727                 }
hmmm, I must have missed the moov.udta.meta.ilst in the ISO spec... no, wait, it isn't there! :-P

Anyway, if this isn't just pure nonsense crusading against foobar2000 and the Nero tags, I don't know what is! Nonsense in comments isn't very becoming, especially when code is GPL. I wonder if I'm next to be insulted in the comments, heh.

Anyway, just wanted to point out the childish behavior here. It's pretty hard to argue the AP author doesn't have something against the Nero / fb2k people. The arguments he writes don't hold water. If it was me, I'd be embarassed. If anything, latest versions of this software are better than the previous versions.

Need I go on?
menno
What's the problem with just skipping the "tags" atom? Is AP trying to parse the "tags" atom for more child atoms? That is just plain wrong.
MelOFlow
Oh, I see you have posted lines finally, so I know you can do it. They weren't the ones that NULLs out the contents of your atom like you claim, but at least you muddled through it. It's futile - it doesn't happen.

So, if you look in the hex you posted, at location 0x0b7b (or there abouts), search for the word 'tags' there. That's a highly stylized NULL - why, it seems to spell out "Nero AAC codec / May 1 2006". If it wasn't nulled out, and was sitting there all the time, that would mean the problem would be elsewhere. You should use a hex editor with a search feature - you would find thing a WHOLE lot faster.

If you feel your implementation should be not be criticized, then you should play by the rules as spelled out in the specification. I quote:

CODE
Type fields not defined here are reserved. Private extensions shall be achieved through the uuid type.


tnrsz: if you have a problem with that, the address your concerns through mp4ra.org I imagine so you can register your atom(s) when there. I'm sure unglamorous comments would be removed once you accommodated the 2 sentences above. fyi: a "field type" is the atom name - as in 'tags'. If you have a problem with Apple, take it to Apple. They can be reached at connect.apple.com. I don't represent them - your issues with 'ilst' rest with Apple.
TrNSZ
Full response coming, sorry.

Edit: I posted a MUCH better response below, with highlighting to point out the issues clearly for everyone to see.

PS - I've highlighed the hex dump in the new post, it's unfortunate you couldn't grok the other one -- especially considering you asked for it.
menno
AtomicParsley.cpp line 2127:
CODE

                    } else if ( strncmp(atom, "tags", 4) == 0 ) { //oh dear, we have foobar2000's prison-rape tags; thick white gelatinous goo oozes out of this atom

                        if (!scan_for_tree_ONLY) { //latch onto scan_for_tree_ONLY as it signals whether we are *really* writing or just getting the tree.
                            
                            jump += dataSize;
                        } else { //we'll just be *showing* the tree, no harm in showing what foobar does to the files...
                            if ( APar_TestforChildAtom(data, dataSize, atom) ) {
                                jump += 8;
                            } else {
                                jump += dataSize;
                            }
                        }



When scanning the tree you try to scan the "tags" atom for child atoms. There are no child atoms in the "tags" atom.
TrNSZ
QUOTE(MelOFlow @ May 26 2006, 15:24) *
Oh, I see you have posted lines finally, so I know you can do it. They weren't the ones that NULLs out the contents of your atom like you claim, but at least you muddled through it. It's futile - it doesn't happen.
You are highly embarassing yourself now! This is highly amusing. Read above for the explanation.
menno
CODE
//we'll just be *showing* the tree, no harm in showing what foobar does to the files...


Funny, in older versions of AtomicParsley.cpp it also scans when not just showing the tree.
MelOFlow
Which AP version are you using? I don't know what version created your file. I don't believe the new one does whatever you think it does. Lemme know if it does and I will endeavor to get it accommodated.
menno
I looked at 0.8: scans everything for child atoms

I looked at 0.8.8: only scans child atoms in "tags" when showing the tree

You should never scan for child atoms in ANY atom you don't know. Simple as that. Teach your parser all the atoms in the spec, and teach it which ones have child atoms, then you can try to scan the whole tree (but still skip the ones you don't know).
It would also be pretty nice if you could remove all the stupid comments from your code.
TrNSZ
QUOTE(MelOFlow @ May 26 2006, 16:20) *

Which AP version are you using? I don't know what version created your file. I don't believe the new one does whatever you think it does. Lemme know if it does and I will endeavor to get it accommodated.

IPB Image
This is with 0.8. No tags were actually changed, just rewritten using AP. Notice the meta count. From "0004" to "0000". This is surely corruption. All the differences are highlighted. You can't deny this. Thanks for admitting your mistake. This is the original version that everyone was complaining about, anyway. The code for 0.8.8 looks better now, and I'll see if the problem still exists or not.

Anyway, thanks for coming around, even if it did take some flaming. :-P

(Attached image, just in case my web server is too slow. What's with the other changes in the file? Who knows. :-P Anyway, please don't claim I can't compare or that things are the same. Let me test 0.8.8 now.)

BTW, thanks for pointing out the specifics, menno. I find it ironic the comments that are bashing fb2k are in the buggy section of the code. =)

Oh, the irony!
TrNSZ
Retesting with latest AP:
CODE
AP warning:
        Setting the [artist...title...album] tag is for ordinary MPEG-4 files.
        It is not supported on 3GP files.
Skipping
The latest 0.8.8 AP is refusing to tag the files generated by foobar2000 and the Nero encoder now. When trying to work with a standard MPEG-4 file (created by iTunes) and then tagged with ND and iTunes tags, and then modified with AtomicParsley 0.8.8, there are no differences.

So the version released 5 days ago, at least in regard to this particular problem is fixed - AP is no longer buggy at least in this respect. Unfortunately, all files tagged with the previous versions of AtomicParsley are corrupted if they contained ND metadata. I'd suggest that everyone who cares about ND tag coherency uses foobar2000 or the upcoming NeroAACtag to rewrite the tags on their files. This also should be a lesson to users of software like this (and the developers) to test their code out thoroughly before using it!

I still say this is a better solution than AtomicParsley, if for no other reason that it writes BOTH sets of tags correctly, but I'll not slam AP any longer in this regard. I still must add, however, that this kind of corruption (along with the "silent" fix a few days ago) combined with the bashing all over of the ND scheme it just happened to corrupt is highly suspicious to me. At least it seems fixed now.

So, can't we all just get along?

Edit: spelling/clarified.
MelOFlow
AP 0.8.8 actively disallows setting iTunes-style metadata on 3gp files. 3gp files are determined by ftyp major brand. If you want to tag a 3gp file you have to use a 3gp asset. If you have a major brand of mp42 or something like that, iTunes-style tags should work. There isn't anything in the 3GPP TS 26.444 version 6.4.0 spec to accommodate iTunes-style metadata - and so there is no support for it in AtomicParsley. The album tag will only be added on 3gp6 & later files. 3gp assets and iTunes-style metadata are strictly separated. For 3gp files, you need:

AP.exe file.3gp --3gp-performer "El Perfomerero" lang=spa UTF16 --3gp-title "The Title"

Here's the cli arguments I was asked to test with for location:
CODE
--3gp-location "Bethesda Terrace" latitude=40.77 longitude=73.98W altitude=4.3B role="real" body=Earth notes="Underground" lang=pol UTF16


The 'tags' fix occurs on Mar21; the latest rolled out release was just recently:
http://svn.sourceforge.net/viewcvs.cgi/ato...ey.cpp?view=log

I'm willing to crawl back under my rock. I will send the request for.... editorial annotations to occur up the line.
=trott=
Spoon, I noticed problems with tags too in dbpoweramp with your new mp4 codec pack. (which supports the new nero aac encoder.)
1) convert flac to m4a using -q.32 (edited options.txt for this)
2) when checking tags, foobar and mp4tag show nothing. tag&rename, itunes and mp4ip tools all show tags.
3) when re-writing tags using tag&rename, same result.
4) when re-tagging from scratch using tag&rename, tags show up in all programs.

What do you use for tagging? Is this the same problem described in this thread?

Also, not related to dbpoweramp, I wonder what happens (as described previously in this thread) what happens when you tag using the nero tagger or foobar, then load the files in itunes and change tags. Since tags seem to be duplicated, won't itunes show the modified tags but foobar show the (non-modified) nero tags?

On a personal note, I must say that this entire situation reminds me of 2 things:
1) the tagging mess that is id3v2. (admittedly this only affected me starting foobar 0.9)
2) the tagging mess that is foobar 0.9. (we are right and everybody else is wrong.)

Foobar is still the best music conversion tool out there, but its ideas of how things ought to be has me searching frantically for alternatives. Nothing suitable found yet though smile.gif


spoon
My guess is the nero encoder writes a simple tag, we write an iTunes tag and fb will only read the nero tag rather than itunes if present?
TrNSZ
QUOTE(=trott= @ May 27 2006, 03:18) *
On a personal note, I must say that this entire situation reminds me of 2 things:
1) the tagging mess that is id3v2. (admittedly this only affected me starting foobar 0.9)
Then you should complain to the ID3v2 people. This exact same kind of complaining happened in the Linux community when KDE made the switch to TagLib, implementing proper ID3v2.4. Everyone is tired of hearing about by now... This is also what happens when everyone uses a broken implementation for so long, and people finally come around and do the right thing.

I'm really tired of hearing about this thing by now, because it's not relegated to just tagging specifications. It's been happening over and over again throughout the history of computers. This actually reminds me of the dark days before PC's, when all different manufacturers produced hardware for the S-100 bus, but often did so very differently. Different vendors hardware could end up blowing up your whole computer (by crossing a voltage and a signal pin, etc). IEEE-696 came along which standardized the S-100 bus - however, many old manufacturers often kept making their cards their way to cater to their existing customers. The standard was there, but everyone did their own thing anyway. In my memory, this was never really sorted out until the IBM PC/XT and PC/AT were released along with their their ISA bus, and everyone who made clones copied the system more or less exactly in this regard. =)
QUOTE
2) the tagging mess that is foobar 0.9. (we are right and everybody else is wrong.)
Exactly what tagging mess are you talking about in foobar 0.9? As far as I know, it's a "victim" of doing things correctly.
QUOTE
Foobar is still the best music conversion tool out there, but its ideas of how things ought to be has me searching frantically for alternatives. Nothing suitable found yet though smile.gif
So what you are saying is you are trying to find software that doesn't implement the latest tagging standards such as ID3v2.4 correctly, and doesn't have any problems reading tags that are completely broken. If that's what you want, go for it.
QUOTE
My guess is the nero encoder writes a simple tag, we write an iTunes tag and fb will only read the nero tag rather than itunes if present?
I expect that you will see a workaround for this and the duplication of tags by the beta release, which should fix a case such as this.
=trott=
QUOTE(TrNSZ @ May 27 2006, 03:53) *

Then you should complain to the ID3v2 people.


My point was: mistakes have been made in the past with id3v2, let's not make them again with mp4 tagging.

QUOTE
Exactly what tagging mess are you talking about in foobar 0.9? As far as I know, it's a "victim" of doing things correctly.


First rule of HA: any quality claims must be proven with evidence. Except when talking about foobar2000, that's like talking bad about the bible.

QUOTE
So what you are saying is you are trying to find software that doesn't implement the latest tagging standards such as ID3v2.4 correctly, and doesn't have any problems reading tags that are completely broken.


I'm saying that I want to find software which works with v2.3 tags when they are present, which works with v2.4 tags when those are present AND which tags mp4/aac/whatever files in a way which makes sure I can actually _read_ those tags in my music player of choice. I have such software. My post was not about id3 but about mp4 tagging. As long as foobar can not add cover art to files I will in any case still require an external tagger.





TrNSZ
QUOTE(=trott= @ May 27 2006, 08:25) *
QUOTE
Exactly what tagging mess are you talking about in foobar 0.9? As far as I know, it's a "victim" of doing things correctly.
First rule of HA: any quality claims must be proven with evidence. Except when talking about foobar2000, that's like talking bad about the bible.
I don't understand you here. Just as this whole thread seems to show, other people love to hate foobar2000 and blame foobar2000 for things, but the problem was (rather embarassingly!) in their software. foobar2000 is not and will not be the all-repairing all-debugging rewriter of buggy and broken tags. If you really want compatability, you have to support the standards. When it comes to the ID3v2 tagging standards, nothing is supporting the standards more exactly than foobar2000, and possibly KDE's TagLib. And the KDE people are bitching too. You can't win.

QUOTE(=trott= @ May 27 2006, 08:25) *
QUOTE
So what you are saying is you are trying to find software that doesn't implement the latest tagging standards such as ID3v2.4 correctly, and doesn't have any problems reading tags that are completely broken.
I'm saying that I want to find software which works with v2.3 tags when they are present, which works with v2.4 tags when those are present
foobar2000 supports ID3v2.3 tags when they are present and valid, and supports ID3v2.4 tags when those are present and valid. How is this not what you want? If you are having problems, you should give us some examples, but this has come up before, and the problem has always been corrupted tags.

One of the reasons people are so defensive about foobar2000 is all the misinformation and blame and general crap being thrown around about "foobar2000 problems" by people who have very little clue what they are talking about. Just re-read this thread for laughs. Alot of this information has already been discussed ad nauseam in prior threads, but people can't seem to figure out how to search. If you feel people here who have to support foobar2000 on their own time for free are often frustrated, you'd be right.

QUOTE(=trott= @ May 27 2006, 08:25) *
AND which tags mp4/aac/whatever files in a way which makes sure I can actually _read_ those tags in my music player of choice. I have such software. My post was not about id3 but about mp4 tagging. As long as foobar can not add cover art to files I will in any case still require an external tagger.
foobar2000 is probably the only program outside of the Nero tools that can produce tags that can be read in any music player, including those that support both iTunes and the ND metadata schemes. The next release of foobar2000 will likely use ND tags only when necessary to supplement metadata stored by the iTunes scheme when possible, thus further increading this compatability. This addresses the concern that `spoon` had earlier in this thread as well, regarding desynced metadata. When it comes to adding cover art, use NeroAACtag (which should be out Any Time Now[tm]).

Anyway, when it comes to compatability, nothing is more compatible than foobar2000 and this will only be greatly inceased with the next release.

QUOTE(=trott= @ May 27 2006, 08:25) *
My point was: mistakes have been made in the past with id3v2, let's not make them again with mp4 tagging.
Unlike the mistakes with ID3v2 tagging, the ND and Apple metadata schemes are not mutually incompatible.

Update: foobar2000 0.9beta4 is out now, and implements the MP4 tagging in a way that will not duplicate metadata across the Apple and ND tags unless there is metadata that cannot be stored losslessly using only the Apple scheme (such as per-chapter data, etc.), making the previous concerns with tag desyncs between different programs a moot point.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.