Portable MP3 player problem

Topic: Portable MP3 player problem (Read 5594 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Portable MP3 player problem

2003-12-31 10:01:15

I wonder if some of the more tech-savvy people here on Hydrogen might be able to provide some help for creating a work-around for a glitch in Frontier Lab's NEX portable MP3 player firmware.

FL has been promising a firmware update for more than a year now that will fix a problem with the track title and artist name from being improperly on the LCD properly for some MP3s. But number of NEX users are getting tired of waiting, and are trying to work around the problem somehow.

For some reason the NEX only displays track title and artist name ID3v2 tags properly on its LCD for MP3s with an even file byte size. MP3s with an odd byte size only display the ID3v2 track title tag, and not the artist name. A 'G' appears before the title when this happens. It's been established that if you sync the ID3v2 tags to the ID3v1 tags, (copy ID3v1 tag info to ID3v2 tags), the problem goes away. For some reason in that process, the resulting file size for the MP3s always seems to an even number of bytes.

I was hoping that it might be possible to create a batch process to insert on byte of a hex value of 00 somewhere into the MP3, and save my longer ID3v2 tags. I found that doing this does create an even file size for all odd size files, and does fix the problem on the surface. But I'm pretty much of a novice at this sort of thing, and I'm not sure if by inserting that one hex value, I might be *#%@!ing up the MP3.

I 1st tried inserting the 00 right after the characters 'ID3' that seem to be at the front of every MP3 I've looked at (not hard spotting my ignorance here). Although that solved the display problem in the NEX, I found that by doing so, I found I had made the ID3v2 tags unreadable in tag editors. The NEX had defaulted back to reading ID3v1 tags, so it still displayed the taps properly.

So to get ID3v2 tags to display, I tried inserting the character right after the ID3v2 tag info, and at the beginning of a number of rows of 00 hex values. The files play and display the tags well that way, but by doing so, I notice all characters that follow to the end of file are pushed one character down. (Do I hear something like fingernails on backboards out there? )

If this, or some other proper method of inserting one hex value can be achieved without doing harm to the files, I'll still need some advice on just how I might go about setting something up to process all of the many MP3s in large libraries.

Thanks for any feedback and suggestions.

Shel

Portable MP3 player problem

Reply #1 – 2003-12-31 16:42:54

The best solution would be to adjust the length of the ID3v2 padding to give a total filesize of an even number of bytes. That said, I don't know of any taggers that will give you byte-level control of the size of the ID3v2 tag (well, getID3() can, but I'm not sure if that's what you're looking for - but if you are able to process all your files with PHP then that'll work nicely).

The safest place to put your padding byte is immediately after the mp3 data. If you're not using APE or Lyrics3 tags, that will be immediately before ID3v1, ie before "TAG" which is always 128 bytes from the end of the file. If you are using either APE or Lyrics3 then the end of the MP3 data is harder to find.

Portable MP3 player problem

Reply #2 – 2003-12-31 19:41:16

Okay... now you'll see how much of a novice I am at all this.

Quote

The best solution would be to adjust the length of the ID3v2 padding to give a total filesize of an even number of bytes.

I've read the term 'padding' being used, and assumed it meant adding null (right term? 00s?) characters to an MP3 or other audio files. But for what reason(s) I never understaood. EG: In EAC 'Compression options' you can set the size of ID3v2 tag padding in kB. I'm guessing that means the data for the various tags will be separated from each other by, say 4kB worth of 00s, yes?. But for what reason?

Quote

That said, I don't know of any taggers that will give you byte-level control of the size of the ID3v2 tag (well, getID3() can, but I'm not sure if that's what you're looking for - but if you are able to process all your files with PHP then that'll work nicely).

Now it's >my< fingers on the blackboard ... I just downloaded a beta version of getID3(), and find it's all files of program code that I have no idea how to execute or write any code for. I studied a little Perl for a while in the 90s, but the learning curve going down that road for accomplishing what I need is awfully steep.

Quote

The safest place to put your padding byte is immediately after the mp3 data. If you're not using APE or Lyrics3 tags, that will be immediately before ID3v1, ie before "TAG" which is always 128 bytes from the end of the file. If you are using either APE or Lyrics3 then the end of the MP3 data is harder to find.

Those ID3v1 'TAG' characters look like just the place. As you say, it's always at the same position relative to the end of the file. So if I could find a hex editor with an easy to configure macro I could run on multiple files, I'd think inserting one 00 character right before it would be a fairly easy task.

I have used WinHex in the past, but I don't recall if it has a feature that will process a group of files. Something like the Word for Windows macro that records a macro as you go through a process would be nice. Tho' when they went from WordBasic to VB I got quite lost.

Shel

Portable MP3 player problem

Reply #3 – 2003-12-31 23:26:09

Quote

I've read the term 'padding' being used, and assumed it meant adding null (right term? 00s?) characters to an MP3 or other audio files. But for what reason(s) I never understaood.

Padding is used in ID3v2 (and a few other tagging formats) to make the tag take up more space than it needs to so that if the tag is later edited to contain more data (longer title, etc) only the tag itself needs to be rewritten, not the entire file. This is only important for tag formats that appear at the beginning of the file (like ID3v2) - tags at the end of the file (ID3v1, APE, etc) have zero (or minimal) data following them, so there's little (if any) extra data to rewrite every time the file is saved. If you set EAC to pad ID3v2 to 4kB, your ID3v2 tag will be written with your data (title, artist, genre, etc) taking up however much it takes up (300 bytes, for example) and the remaining 3796 bytes filled with nulls to make up the total 4kB you selected. So then you could later come back and edit the ID3v2 tag to contain another 3.5kB of data (song lyrics for example) and the whole file would not need to be rewritten, just the 4kB containing the tag.

Quote

I just downloaded a beta version of getID3(), and find it's all files of program code that I have no idea how to execute or write any code for.

You'll need a web server running PHP for starters. If you're unfamiliar with PHP this might be more complexity than you bargained for...

Quote

Those ID3v1 'TAG' characters look like just the place. So if I could find a hex editor with an easy to configure macro I could run on multiple files, I'd think inserting one 00 character right before it would be a fairly easy task.

If you use Lyrics3 (I hope not) or APE tags (you might do so without knowing it - MP3Gain applies APE tags for undo information; foobar2000 likes APE tags) these appear immediately before ID3v1 and so adding a byte of padding before ID3v1 will break them. If you don't care about APE tags getting broken then go ahead and insert 1 byte of null 128 bytes from the end of the file, right before "TAG".

I use UltraEdit as my editor of choice, which works well in hex mode as well. It has macro capabilities, although I have not really explored them. You might play around with the demo version to see if it can meet your needs.

Portable MP3 player problem

Reply #4 – 2004-01-01 01:27:32

Quote

So then you could later come back and edit the ID3v2 tag to contain another 3.5kB of data (song lyrics for example) and the whole file would not need to be rewritten, just the 4kB containing the tag.

Okay... great. Thanks for laying that out for me. That explains what I had been seeing in the hex editor. And I've noticed that when modifying some tags, the file size of the MP3 never changed. That would make sense then if null characters are just being replaced by ASCII characters for the modified tags.

However the other night I noticed that one MP3 I wrote more text to the track title tag actually >did< get bigger in file size. And when I've synced the ID3v2 tags to be filled with data from the ID3v1 data, the size of some MP3s shrank. It would seem that somehow, data is being inserted and deleted to/from the middle of the file without affecting the MP3.

Quote

You'll need a web server running PHP for starters. If you're unfamiliar with PHP this might be more complexity than you bargained for...

Si sigñor

Quote

If you use Lyrics3 (I hope not) or APE tags (you might do so without knowing it - MP3Gain applies APE tags for undo information

Hmmmm.. I >do< have some MP3s I've processed with MPGGain. I suppose I can group them together the MP3s in question, undo their gain, set the 00 byte, and then set the gain again for all. More work for a macro though.

Quote

foobar2000 likes APE tags) these appear immediately before ID3v1 and so adding a byte of padding before ID3v1 will break them.

How about insert the byte before the APE tag?

Quote

I use UltraEdit as my editor of choice, which works well in hex mode as well. It has macro capabilities...

Thanks for the suggestion. I'll give it a whirl.

BTW: I read your post in Validated News about the 'Warn: (0%)' suddenly appearing below your avatar when the site was revamped the other night. Do you know if one of the site operators correct that for you individually? From what I read there, this was a glitch that popped up during the site update. At this point, I haven't seen anyone with the problem with their account except me, though there very well may be with the large numbers of members here.

Shel

Portable MP3 player problem

Reply #5 – 2004-01-01 02:22:16

Quote

one MP3 I wrote more text to the track title tag actually >did< get bigger in file size. And when I've synced the ID3v2 tags to be filled with data from the ID3v1 data, the size of some MP3s shrank.

Padding is there for the tag editor to use intelligently - there's no requirement for them to do so. Suppose you have a file with a padded 4kB ID3v2 tag, and you edit it, adding a few bytes more data, giving a total data size of 1kB. The smart tag editor should rewrite only those 4kB putting the new tag in place of the old tag - that's the purpose of padding. A dumb tag editor could end up rewriting the file with an unpadded 1kB tag, or even padded to 2kB or whatever it's preferences happen to be. Perfectly legal, but the whole idea of padding is to remove the need to rewrite the entire file when the tag is updated. The editor could also increase the size of padding when saving the new tag (if it so chose), once again necessitating a rewrite of the entire file. So rewriting a tag that fits in the existing padded size with a good editor should not change the size of the tag; with a bad editor the filesize may well change (larger or smaller).

Quote

How about insert the byte before the APE tag?

That's what you should do, yes. It's just that finding the start of the APE tag is harder than finding the start of the ID3v1 tag. The APE tag has a 32-byte header and footer block at the beginning and end of it - both blocks are almost identical, and start with "APETAGEX" - you should insert the spare padding byte before the 1st occurance of APETAGEX. Be aware that "APETAGEX" could conceivably occur as part of the MP3 data itself (as with any random pattern of bytes) so searching for 2nd-from-the-end would be the wiser idea than 1st-from-the-beginning.

Another option also exists - inserting data between ID3v2 and the audio data, which is harder to find (it should be the first 0xFF character that's not followed by 0x00, but I'm not sure that UltraEdit supports binary regular expression matching). The padding of ID3v2 is supposed to be nulls, so you could conceivably insert a spare null anywhere in that padding. If you know that all your ID3v2 tags are padded to more than 1kB, and that all your ID3v2 tags are shorter than 1kB, you could simply insert a spare null at offset 1024 and it should work ok too.

Putting the spare byte before the APE tag would be the better/safer option however, as it won't break anything (inserting a byte between ID3v2 and audio without adjusting the ID3v2 size will slightly break ID3v2-aware players, as they won't find the start of audio where the expect it, but have to seek byte by byte until they find it, in this case one byte later. All MP3 players should skip unknown data until they find audio data - that's how ID3v2 works in the first place

Quote

...'Warn: (0%)' suddenly appearing below your avatar... I haven't seen anyone with the problem with their account except me

I think everyone now sees the warn percentage for their own account only. At least I've seen atici, Sebastian Mares, john33, kwanbis, Liquid Predator, Continuum, Xenno, Triza, etc mention the same issue

Portable MP3 player problem

Reply #6 – 2004-01-01 04:45:57

Quote

A dumb tag editor could end up rewriting the file with an unpadded 1kB tag...

This may be what was going on with the GearVolt tag editor I helped beta test for Robert Wahler a while back. I'm only starting to learn a bit more about the technical end of things at this point. But after reading what you've written here, I suspect Robert's code must be re-writing the entire file. I've noticed that modified ID3v1 tags get written quickly. But if I've modified the ID3v2 tags for an entire album of MP3s, the process of updating the tags takes quite a while on the little under-powered Libretto notebook I keep my MP3 library on. While testing writing data with WinHex, it has to re-write the entire file if I insert that null character, and the time it takes on this notebook is about the same time it takes Gearvolt to update ID3v2 tags

I also noticed that GearVolt couldn't read ID3v2 tags anymore after I inserted a null character in a long column of null characters between the end of the ID3v2 tag, and the audio data. This while WinAmp was able to read them.

Quote

The editor could also increase the size of padding when saving the new tag (if it so chose), once again necessitating a rewrite of the entire file.

Okay... that makes sense if there was only a small amount of tag space allotted when the file was 1st created. That way a tag editor could expand the space needed to write the tag if needed.

Quote

...so searching for 2nd-from-the-end would be the wiser idea than 1st-from-the-beginning.

Sounds like a piece of cake.... that is if I knew a bit more about writing code. Seems like the process would be basically:

- Go to the end of file
- Search backwards for '"TAG"
- Check characters to the left for "APETAGEX"
- - If present, then search upwards for 2nd occurrence and proceed as below
- If not present, or if 2nd occurrence of "APETAGEX" has been found, insert '00' before "TAG" or "APETAGEX"
- save file

Though from the little WordBasic I worked with, some monkey-wrench will drop into the gears before it'll work.

Quote

Another option also exists - inserting data between ID3v2 and the audio data, which is harder to find (it should be the first 0xFF character that's not followed by 0x00

That 0x00 and 0xFF threw me a for a loop until I found an explaination that it's a way of representing hexidecimal values in program code. 00 and FF I know. But 0x00 and 0xFF ...

Quote

but I'm not sure that UltraEdit supports binary regular expression matching). The padding of ID3v2 is supposed to be nulls, so you could conceivably insert a spare null anywhere in that padding.

I'm having a bit of a problem with UltraEdit. I can't seem to undo, or insert hex values for some reason. I was just starting to get WinHex under my belt from hours of data recovery

Quote

If you know that all your ID3v2 tags are padded to more than 1kB, and that all your ID3v2 tags are shorter than 1kB, you could simply insert a spare null at offset 1024 and it should work ok too.

I think going in from the end of the file sounds the better route.

Quote

I think everyone now sees the warn percentage for their own account only.

So if I log out, and then check my posts, maybe it's not there? I'll check.

Shel

Portable MP3 player problem

Reply #7 – 2004-01-01 04:54:46

Quote

I think everyone now sees the warn percentage for their own account only.

Si.... Bueno!

Portable MP3 player problem

Reply #8 – 2004-01-01 07:03:12

Wouldn't it just be easier to NOT use v2 tags?

Portable MP3 player problem

Reply #9 – 2004-01-01 09:26:43

Quote

Wouldn't it just be easier to NOT use v2 tags?

Sure if your MP3 library isn't half full of recordings of classical music with long titles for compositions and equally wordy movements.

For example:

Johann Sebastian Bach - Das Kantatenwerk Vol. 1 (2,2) - 04 - Es mag mir Leib und Geist verschmachten.mp3

Il Giardina Armonico - Vivaldi, The Four Seasons - 07 - L'Autunno - I Allegro - Allegro Assai.mp3

Portable MP3 player problem

Reply #10 – 2004-01-01 17:50:28

Quote

I also noticed that GearVolt couldn't read ID3v2 tags anymore after I inserted a null character in a long column of null characters between the end of the ID3v2 tag, and the audio data.

If a tag editor can't read ID3v2 tag independant of the audio data that comes after it, something is seriously wrong with the editor.

Quote

- Go to the end of file
- Search backwards for '"TAG"
- Check characters to the left for "APETAGEX"
- - If present, then search upwards for 2nd occurrence and proceed as below
- If not present, or if 2nd occurrence of "APETAGEX" has been found, insert '00' before "TAG" or "APETAGEX"
- save file

That sounds like a decent way to go about it. If you can figure out how to script that

Quote

I'm having a bit of a problem with UltraEdit. I can't seem to undo, or insert hex values for some reason.

Control-D brings up Hex Insert/Delete (make sure you select the Insert radio button), and then choose the number of bytes you want to insert (in your case, 1).
If UltraEdit has opened the file without a temp file then no undo is available. Check your configuration under Advanced | Configuration | General | Open file without temp file.

I'm utterly amazed at how many messed up implementations of tag readers there are on portables, from misinterpreting APE as ID3v1 even though its not 128 bytes from the end of the file, to this only-read-ID3v2-if-even-bytesize. I find it very strange that hardware makers have so much trouble programming relatively simple things

Portable MP3 player problem

Reply #11 – 2004-01-01 22:54:35

Quote

If a tag editor can't read ID3v2 tag independant of the audio data that comes after it, something is seriously wrong with the editor.

I'll have to get in touch with Robert. I must say that he >is< fast at fixing bugs.

Quote

That sounds like a decent way to go about it. If you can figure out how to script that

Something that would have been a breeze back when I was usinf WordBasic. But I never figured out how to run one of those macros on a batch of files.

Quote

Control-D brings up Hex Insert/Delete (make sure you select the Insert radio button), and then choose the number of bytes you want to insert (in your case, 1).

Okay... By default it inserts a '20' hex value. WinHex prompts me for a specific hex vaule to insert. I can just insert the extra 0 over the 2 easily... though not being that familiar with these sorts of things, the 20 may be okay?

Quote

Check your configuration under Advanced | Configuration | General | Open file without temp file.

Hmmmm.... It's already set to use the temp file by default. I thought maybe I had to 1st save the file after the change. But 'Undo' was still grayed out as disabled in the Edit menu.

Quote

I'm utterly amazed at how many messed up implementations of tag readers there are on portables

From what I've been reading on the NEX II support group, most all portable MP3 players have pretty glitchy firmware. TheiPod is about the only one with relatively few bugs... but heck, one would expect that from Steve and the boys over there.

Quote

I find it very strange that hardware makers have so much trouble programming relatively simple things.

This is a consistant gripe in the NEX group. Frontier Labs has been promising a fix for this and a number other bugs for over a year. We haven't seen a firmware update for about 18 months at this point.

Shel

Portable MP3 player problem

Reply #12 – 2004-01-02 00:38:17

Quote

MP3Gain applies APE tags for undo information; foobar2000 likes APE tags) these appear immediately before ID3v...

I opened a bunch of MP3s I've applied MP3Gain to, and didn't find the "APETAGX" tag anywhere in the files that were processed with MP3Gain Back End v1.0.3, and MP3 GAIN v0.6.6. It seems to have been implemented somewhere up to Back End v1.4.3, and MP3 GAIN v1.2.2. Most of my MP3s were processed with the older version.

Also: The "APETAGX" tag created with MP3Gain v1.4.3 doesn't appear immediately before the ID3v1 'TAG' characters. It's 25 characters back, and has 2 program characters in between. I'd then have a script search back to the 'TAG' characters to insert the null character.

Quote

- Go to the end of file
- Search backwards for '"TAG"
- Check characters to the left for "APETAGEX"
- - If present, then search upwards for 2nd occurrence and proceed as below
- If not present, or if 2nd occurrence of "APETAGEX" has been found, insert '00' before "TAG" or "APETAGEX"
- save file

I can see already another bug there already if the MP3 doesn't have any ID3v1 tag.

Shel

Portable MP3 player problem

Reply #13 – 2004-01-02 02:46:13

Quote

I opened a bunch of MP3s I've applied MP3Gain to, and didn't find the "APETAGX" tag anywhere in the files

Right - I believe APE tags were added in MP3Gain v1.2-beta (June 19, 2003).

Quote

Also: The "APETAGX" tag created with MP3Gain v1.4.3 doesn't appear immediately before the ID3v1 'TAG' characters. It's 25 characters back, and has 2 program characters in between.

"APETAGEX" is the first 8 of 32 bytes that form the header/footer of the APE tag. The other 24 bytes will generally be binary bytes of various kinds, depending what values are stored in the header. See here:
http://www.personal.uni-jena.de/~pfk/mpp/sv8/apeheader.html

Quote

I can see already another bug there already if the MP3 doesn't have any ID3v1 tag

So the best solution would be to make all your files tagged consitantly, all with APE + ID3v1. Then your scripting will be much easier/more reliable.

Portable MP3 player problem

Reply #14 – 2004-01-02 11:03:24

Quote

"APETAGEX" is the first 8 of 32 bytes that form the header/footer of the APE tag. The other 24 bytes will generally be binary bytes of various kinds, depending what values are stored in the header.

If this is true, then it looks like MP3Gain is adding 8 bytes of padding after the 8 bytes of the header, and before its own tag elements. I don't see a way to display fixed width fonts here, but this is the end of a Beatles MP3 I tested with MP3Gain:

UAPETAGEXÐ...®..
....... ........
.........MP3GAIN
_MINMAX.116,208.
.......MP3GAIN_U
NDO.+000,+000,N.
.......REPLAYGAI
N_TRACK_GAIN.+2.
400000 dB.......
.REPLAYGAIN_TRAC
K_PEAK.0.600143A
PETAGEXÐ...®....
......€........T
AGNorwegian Wood
(This Bird
Ha..Beatles.....
..............Ru

Quote

See here: http://www.personal.uni-jena.de/~pfk/mpp/sv8/apeheader.html

Hmmm I can understand "Preamble" and "Reserved' as probably representing the terms "Header" and "Footer" that you're using, and the 64 bits they represent. But I can't quite figure out the info on what comes between there.

Quote

So the best solution would be to make all your files tagged consitantly, all with APE + ID3v1. Then your scripting will be much easier/more reliable.

Good suggestion... thx.

Shel

Portable MP3 player problem

Reply #15 – 2004-01-02 11:09:13

Quote

If this is true, then it looks like MP3Gain is adding 8 bytes of padding after the 8 bytes of the header...

Sorry, that should read, "it looks like MP3Gain is adding 8 bytes of padding after the >32< bytes of the header..." I had it right before I edited the 32 to an 8 at the last moment.

Shel

Portable MP3 player problem

Reply #16 – 2004-01-02 15:48:57

Quote

I don't see a way to display fixed width fonts here

You can specify Courier font, or put the whole chunk inside a [ CODE ] block (the better way in your case - I can't do it here because I'm using color highlighting so I'll do the courier font thing)

Quote

If this is true... it looks like MP3Gain is adding 8 bytes of padding after the >32< bytes of the header

OK, this took a long time to highlight in all these colors so pay attention!

-----------------------------------------------------------
UAPETAGEXÐ®
_
MP3GAIN
_MINMAX116,208
MP3GAIN_U
NDO+000,+000,N
REPLAYGAI
N_TRACK_GAIN+2.
400000_dB
REPLAYGAIN_TRAC
K_PEAK0.600143A
PETAGEXÐ®
€T
AGNorwegian_Wood
(This_Bird______
HaBeatles
Ru
-----------------------------------------------------------

from http://www.personal.uni-jena.de/~pfk/mpp/sv8/apetag.html
APETAGEX = "Preamble", equal to string "APETAGEX" (64-bit = 8 bytes)
Ð = "Version Number", equal to 2000 (32-bit = 4 bytes)
® = "Tag Size", equal to 194 (32-bit = 4 bytes)
= "Item Count", equal to 4 (32-bit = 4 bytes)
_ = "Tag Flags" (32-bit = 4 bytes)
= "Reserved" (64-bit = 8 bytes)

That makes for a total of 8+4+4+4+4+8 = 32 bytes for the header. After that comes each of the tag items, which each consist of ItemSize + ItemFlags + ItemKey + KeyTerminator + ItemValue:
http://www.personal.uni-jena.de/~pfk/mpp/sv8/apetagitem.html

= "Item Size" (32-bit = 4 bytes)
= "Item Flags" (32-bit = 4 bytes)
MP3GAIN_MINMAX = "Item Key" (variable length)
= null key/value seperator
116,208 = "Item Value" (variable length)

This pattern repeats 4 times for the data, and then the footer follows which is a near-copy of the header.
The first part of the ID3v1 tag is bolded at the end of the sample you quoted.

Quote

If this is true... it looks like MP3Gain is adding 8 bytes of padding after the >32< bytes of the header

So those 8 bytes beyond the 32 bytes of the header are not part of the header, but rather the size and flags of the following data item.

Portable MP3 player problem

Reply #17 – 2004-01-04 05:31:50

Quote

You can specify Courier font, or put the whole chunk inside a [ CODE ] block (the better way in your case - I can't do it here because I'm using color highlighting so I'll do the courier font thing)

Courier as a fixed-width font! Okay... That's new to me, but why not?

Quote

OK, this took a long time to highlight in all these colors so pay attention!

Nice work. A few problems with the fixed width of some characters being displayed as boxes instead of bars. But okay... I can see the positions where things are supposed to be written to. But I still can't seem to locate an explaination of just what these things are, and what they do. I had to struggle to refresh my understanding binary, decimal, and hex math. But I'm still not understanding much about APE tags, and what's going on here:

Ð = "Version Number", equal to 2000 (32-bit = 4 bytes)

Version Number: I guess that this is the APE version is obvious. V1 = 1000, and V2 = 2000. But I don't see how one could interpret the characters Ð as representing 2000, uness there's a cross-reference somewhere that equates those chararters to a value of 2000. Actually, we're missing the 2nd character in that 4 byte string which is 07 in hex, the whole string being: D0 07 00 00

® = "Tag Size", equal to 194 (32-bit = 4 bytes)

Tag Size - The definition of this on the APE tag web page says, "Tag size in bytes including footer and all tag items excluding the header to be as compatible as possible with APE Tags 1.000"

This represents the size of the complete set of APE data in the audio file containing it. Yes? So the size will vary with the individual audio file, and the data for the APE tags it contains? If so, I don't see where the values ® are interpreted as 194 (which I presume means the the entire APE data consumes 194 bytes, or not?), unless again there's a list of reference values somewhere that those values can be equated to. The hex values of the tag are: AE 00 00 00 ... And converting hex to decimal, AE would be 160 + 15 = 175. I'm obviously missing something.

Are these program characters in the "Version Number" & "Tag Size" components that software reads as "2000" & "194"?

I'll not go through the entire list, but I can't find any definitions for the rest of these things, and explanations of just what they do:

For APE Tag Header/Footer Version 2.0:
Item Count
Tag Flags
Reserved

For APE Tag Item:
ItemSize
ItemFlags
ItemKey
KeyTerminator
ItemValue

I'm also having a problem with the hierarchy of these APE components on the pages for Basic Components of a SV8 Stream. Between a problem trying to project the stucture of these components in my mind, and my innate dyslexia, my head has been spinning trying to make some order out of the APE information while jumping from link to link on those APE web pages.

I've probably gotten a lot wrong here, but in order to make some sense out of the structures there, I tried to construct an outline of it all. However I'm still in the dark when it comes to what the definitions and purposes are for many components. Does this look like it depicts a semblance of APE component structure:

*****************************************************

Basic Components of a SV8 Stream:
--- APE Tag Version 2.0
------ APE Tags Header/Footer Version 2.0 (32 byte)
--------- Preamble
--------- Version Number
--------- Tag Size
--------- Item Count
--------- Tag Flags
--------- Reserved
------ APE Tag Item 1 (10 byte)
--------- ItemSize
--------- ItemFlags
--------- ItemKey
------------ Title
------------ Subtitle
------------ Artist
------------ Album
------------ Debut Album
------------ Publisher
------------ Conductor
------------ Track
------------ Composer
------------ Comment
------------ Copyright
------------ Publicationright
------------ File
------------ EAN/UPC
------------ ISBN
------------ Catalog
------------ LC (Label Code)
------------ Year
------------ Record Date
------------ Record Location
------------ Genre
------------ Media
------------ Index
------------ Related
------------ ISRC
------------ Abstract
------------ Language
------------ Bibliography
------------ Introplay
------------ Dummy
--------- KeyTerminator
--------- ItemValue
------------ Integer Number
------------ Floating Point'-' character
------------ Date
------------ Time period
------------ String
------------ List of entries
------------ Time Stamp
------------ Lyrics
------------ Media
------------ Title Number
------------ Weblink
------------ Local Link
------------ Other IP link
------------ e-Mail address
------------ Binary data
------ APE Tag Item 2 (10 byte)
--------- Ditto "APE Tag Item 1" above
------ APE Tag Item n-1 (10 byte)
--------- Ditto "APE Tag Item 1" above
------ APE Tag Item n (10 byte)
--------- Ditto "APE Tag Item 1" above
------ APE Tags Footer (32 byte)
--------- ItemSize
--------- ItemFlags
--------- ItemKey
--------- KeyTerminator
--------- ItemValue

*****************************************************

Or might there be a URL where this is laid out a bit better?

And oh... You wouldn't know anything about where XAudio puts it's data for MusicMatch volume leveling, would you? I haven't gotten feedback on that here.

Shel

Portable MP3 player problem

Reply #18 – 2004-01-04 16:16:17

Quote

But I don't see how one could interpret the characters Ð as representing 2000...the whole string being: D0 07 00 00

D0 07 00 00 does equal 2000 - it's hexadecimal values stored in what is known as Little-Endian format, which basically means that the bytes are written "backwards" from how you might normally read them. So translated into what you expect to see, that would be 00 00 07 D0, and 7D0 in hex does equal 2000.

Quote

This represents the size of the complete set of APE data in the audio file containing it. Yes? So the size will vary with the individual audio file, and the data for the APE tags it contains? If so, I don't see where the values ® are interpreted as 194 (which I presume means the the entire APE data consumes 194 bytes, or not?)

I calculated 194 based on the data you copy-pasted to me from the tag, it's quite possible that some of the data was lost in the posting. If the value of that field is indeed AE 00 00 00 that has a decimal value of 174, which means that the APE tag is 174 bytes long, plus 32 bytes for the header, for a total of 206 bytes of data.

Quote

I'm also having a problem with the hierarchy of these APE components... Does this look like it depicts a semblance of APE component structure:

The basic structure of an APE tag is:
[32 bytes of header, with size/version/count/etc info]
any number of data items go here, repeat this as needed:
* [length in bytes of data value] (4-byte field)
* [4 bytes of flags, indicating the type of data stored in this field]
* [item key, which is text such as "ARTIST" saying what this data is]
* [one null seperator byte, indicating end of field name, start of value data]
* [actual field data, length is specified above]
[32 bytes of footer, copy of header but with 1 flag bit changed]

Quote

You wouldn't know anything about where XAudio puts it's data for MusicMatch volume leveling, would you?

Not offhand, no - but I'd be happy to look into it if you want to send me a sample file, either to http://www.getid3.org/upload or email to me directly.

Portable MP3 player problem

Reply #19 – 2004-01-05 05:08:35

Quote

D0 07 00 00 does equal 2000 - it's hexadecimal values stored in what is known as Little-Endian format, which basically means that the bytes are written "backwards" from how you might normally read them. So translated into what you expect to see, that would be 00 00 07 D0, and 7D0 in hex does equal 2000.

Little-Endian... Okay, that's recent history for me with my experiences recovering data with WinHex. Something I get to apply now:

Let's see...

700 hex = 7 x 256 = 1792
D0 hex = 13 x 16 = 208
1792 + 208 = 2000

Okay... I can't believe how poor I am at remembering my multiplication tables. I was at that for 15-20 minutes, and had to resort to a hex converter to find my error.

Quote

Quote
..I don't see where the values ® are interpreted as 194

I calculated 194 based on the data you copy-pasted to me from the tag, it's quite possible that some of the data was lost in the posting. If the value of that field is indeed AE 00 00 00 that has a decimal value of 174, which means that the APE tag is 174 bytes long, plus 32 bytes for the header, for a total of 206 bytes of data.

The hex values for ® were AE 00 00 00 ... So reversing it to 00 00 00 AE is pretty straightforward: 'A' hex = 16 x 10 = 160 + 14 (E hex) = 174.

Quote

APE component structure:
The basic structure of an APE tag is:
[32 bytes of header, with size/version/count/etc info]
any number of data items go here, repeat this as needed:
* [length in bytes of data value] (4-byte field)
* [4 bytes of flags, indicating the type of data stored in this field]
* [item key, which is text such as "ARTIST" saying what this data is]
* [one null seperator byte, indicating end of field name, start of value data]
* [actual field data, length is specified above]
[32 bytes of footer, copy of header but with 1 flag bit changed]

Alright... I don't see any discrepancies between this and what I laid out. Just that I neglected to indicate which components were optional. It's just that I really need to have a complete layout of all elements to get things into my head.

Is there no other information on APE tag structures on the net beside the site you originally pointed me to?

Quote

Quote
You wouldn't know anything about where XAudio puts it's data for MusicMatch volume leveling, would you?

Not offhand, no - but I'd be happy to look into it if you want to send me a sample file, either to http://www.getid3.org/upload or email to me directly.

Okay, I'll upload the file we're discussing, and another one.

I'm not completely sure if MusicMatch is actually writing the volume leveling to the MP3, or keeping a database file somewhere. But from the reply I got from MM support, it sounded like the data was going right into the files.

For comparison purposes, at some point I'll see if I can find older copies of a few of my MP3s that were not processed by MM for sound leveling. It might be easier to spot where the data's written that way.

Shel

Notice