I don't know if this is a DOpus behaviour or something related with the script language, but why when you grab info from track number, DOpus cut down all the left zero digits?
ex. If track number is 02, Dopus gets 2, and so on.
could you please consider fix(if possible) this behaviour?
Thanks
This is usually an explicit setting applied to how the track info is saved... and I forget which ID3 Tag version allowed this (maybe all).
In any case, in what exact scenario are you seeing hits? I don't know what you mean when you say "why when you grab info from track number"... what are you doing and then where are you seeing the leading 0's getting trimmed? In details view mode in columns showing the track number, or something in the actual scripting interface (AudioMeta object)?
Since you mentioned scripting - I went ahead and wrote a test script and it looks like the mp3track property that the scripting interface is giving us access to is of type: LONG. I rather imagine that because of this, VBscript (or Opus as it fills in this property before passing to us) is simply trimming the leading 0 when it casts it as a long.
If I have deduced close to correctly - I think GPSoft should consider changing this to a string value to be able to properly reflect the actual value of the tag. Maybe even a better argument for such a change is that if you use the "01 / 12" format for the track number value - Opus is still sending through a LONG value of "1"... which isn't the actual value in that tag field...
Let's see what they say.
It might make sense to have a separate property that returns the raw string value. I think returning the numeric value is also useful, though, since it saves scripts from having to parse strings into numbers (and the strings can be in so many different formats, given the wide variety of MP3 tagging non-standards).
That said, if you want the value to be padded to two digits, you can do it yourself in your script, so I'm not sure why this is important for the padding on its own?
(I can see why you might want the raw string to get the total number of tracks, although Opus parsing that and providing it as a second LONG property may be a better idea. I can also see why you might want to be able to set the raw string in the future, if we ever add a SetMetadata method, as then you get full control over how the data is written to the file, although I think it's read-only right now.)
Well, I think its great if you try to make stuff less complex for users and I fully agree that treating that value as a numeric can be useful - in fact, I'll even admit that that will probably be useful more often than not in most obvious use-cases. But uber-noobs probably won't really be scripting that much in the first place 
... and it's not that hard to check that value and split() it on chars like the slashes that would make CLng or int-like conversion functions puke on the char. But more importantly, not knowing what the heck people might end up doing with the info in this tag, I would think that the accuracy of the data being reported would trump a perceived need to mask the sort of complexities you're trying to protect people from, no?
Case in point (as to why I might even care in the first place 
)... I got my son a cheap little mp3 player a few years ago. An intentional gift of a piece of garbage mp3 player because I wasn't ABOUT to let him blow a $50 - $100 investment in a slightly less crappy / slightly more capable mp3 player the first time he left it on the bus (which happened BTW - bye bye). The thing actually choked hard and DIED when adding tracks with the "track/total" format in the track field... to the point where I went back to the drug store TWICE to return and exchange it. Only to figure out on round 3 that it was actually the "track/total" format thing. I remember missing the ability to do an Opus Find for tracks with that format in the track field (I think Opus only let you search for numeric values in that field back then or something?)... to find and then "fix" any such tracks in our collection...
Back to your very valid point (and I'm not trying to deconstruct my own argument here )... even if I'm not personally daunted at having to convert the real value in that field, I agree it'd be helpful to help ppl who aren't so inclined to take that job on themselves. And since it seems you guys have already done some work to cover up the craziness that ID3 tags sometimes come with, why not consider returning the actual (and accurate) data in that tag field, and consider making the work you've already done to convert that value available for use as a special metadata method people can call to make short work of the job and take advantage of what you've done - when desired?
Just my opinion of course ... if you can add a property to pass through the un-massaged value then I think that would be good. But I would think it'd be preferable to do that in the property that maps to the keyword that is supposed to hold that data, since that's what is actually in that field. And then have alternate properties for whatever massaged versions of the data that you're returning now just for sake of consistency. I thought it was smart to refer us to the column and metadata keywords as the properties for the audio metadata object... so why pass back data that is different in the way that keyword is displayed in the lister in the script object.
Semantics... I know. Either way I'm glad you'll consider finding someplace to pass the unaltered string...
Edit Note: the thought also did occur to me that you guys don't necessarily want to be in the business of fielding support cases asking why users who are trying their hand at scripting get errors when trying to use a string value with slashes or some other crazy value in that field that flies in the face of standards . Fair enough - lol.
Because, Im being doing an Autohotkey script, that lets you format the metadata via template(is very useful), and do a padding task whenever is needed, but since all the track info is already cut down, they do in all the files, and since after do the format, the script compare if they are changes between the input and output, all the files are been changed, imagine this problem with too many files that already have padded track info, but DOpus retrieves as they are not.
The text fields were added to the scripting interface in the beta released this morning.
Thanks alot!
Just a comment about the description in the B6 announcement... these fields were described in the B6 notes as:
The 'Properties' description confused me for a second - as the specific individual keywords are the 'properties' available under the Item.metadata.audio 'Object'. It looks like you've actually defined a set of new *_text companion objects for eqach of the previous defined metadata objects. So as it relates to this thread, instead of:
Item.metadata.audio.mp3trackwe can use:
Item.metadata.audio_text.mp3trackWORKS FOR ME...
TRIVIAL NOTE: as far I'm concerned anyway, and this may be taglib and not Opus itself. My test track had a track number value of "04 / 08". Both the lister display for this column and the new string property for it in the script interface drops the spaces between the slash and numeric parts of the string - so, "04/08". Possibly the sort of standards craziness Leo mentioned or something Taglib assumes it should do to closer adhere to some standard 
...?
Objects can be returned via properties of other objects.
Metadata.audio_text is a property, just like the old Metedata.audio was a property (returning an AudioMeta object).
Ok, guess I was taking all the 'type' column info in the reference to literally...
Fair enough, property is a fairly overloaded term.
Yeah, expect so... wasn't so much an "aha" at you for documentation so much as the use of the term made me unsure of how to make use of it . No shortage of my slop code instabilities have been due to me incorrectly using some of the ~properties.