Weird problem...

My iRiver iMP-350 SlimX can't properly display ID3v1 tags after the MP3Gain "normalization".

Here's what I did:

1) Ripped the CD to .wav using EAC
2) Encoded in --alt-preset standard -Y with Lame 3.90.3 (using razorlame frontend)
3) Tagged the mp3s using ID3v1 with Tag'n'Rename (great program, never had problems with it)
4) MP3Gain'd the mp3s using Track Analysis so they all sound the same volume (using latest version - 1.2beta)
5) Burned them using latest Nero version (5.5.10.35)

At first I thought something went wrong during the recording proccess. So I burned another RW with Nero, but the same thing happenned - All the tags were corrupted in SlimX.

I changed my burning software to see if it was Nero's fault. I installed CDBurnerXP and burn another CD. Guess what: same problem.

Apparently, the problem is with MP3Gain. Does it writes the "undo info" into the mp3 tags? That's probably why SlimX can't display them. Instead, it displays garbage

I can upload one of these mp3s for you guys to analyze, but I think you can easily recreate the problem if you have an iMP-350.

Any ideas? I never had this problem before, I think I was using a previous version of MP3Gain.

P.S.: Winamp can read the mp3gain'd mp3s tags perfectly

Yeah, upload one of the mp3s so I can look at it.
Hopefully it's simply the fact that the SlimX gets confused by the APEv2 tag that MP3Gain 1.2 Beta uses to store undo information.
If that's the case, you can use the "Options - Tags - Remove Tags from files" function to delete the APEv2 tags. Of course, you'll lose the undo information in the process...

It's always possible that there's something else wrong, though, and 1.2 Beta really is screwing up the ID3v1 tag when it writes the APEv2 tag. That's why I want to look at one of your files.

(edit) - Oh, I just noticed your P.S. That makes it much more likely that the SlimX really is having problems with the APE tag.
Crap. That means I'll probably have to add ID3v2 "undo" tag support. I really was hoping to avoid that...

-Glen

Yeah, you should avoid that. Maybe you can delete the ID3v1 comment and add the undo info there. There are plenty of reasons already discussed in this board not to use ID3v2. But i'm sure you know that better than me

I've noticed there are 2 different problems when SlimX displays the tags:

Case 1 - Although the tag isn't properly displayed, some characters are correct. Eg.:

Filename: 01-korn-dead.mp3 (--alt-preset standard -Y)
Artist: Korn
Title: Dead
SlimX displays: "ead"

Case 2 - The tag is completelly messed up. Eg.:

Filename: 01-36_crazyfists-turns_to_ashes.mp3 (CBR 192)
Artist: 36 Crazyfists
Title: Turns To Ashes
SlimX displays: erm... something like "CSBEGININD00000200CRC(...) - eXd"

There's also a third case:

Case 3 - The mp3 was replaygain'd like all the other ones and its tags are ok. Eg.:

Filename: 01-incubus-privilege.mp3 (--alt-preset standard)
Artist: Incubus
Title: Privilege
SlimX displays: Incubus - Privilege B)

Links:
Case 1
Case 2
Case 3

Thanks for your effort

Edit: Typo

As someone who uses exclusively id3v2.3 (no 1.1 or APE tags) I would certainly be interested in having the undo feature use them. Hey come on people - face it: we use MP3 because it works with portables! APE doesn't! If i have a player that reads APE, it probably reads MPC too, so MP3 with APE is sort of a redheaded stepchild.

Case 3 has an ID3v2 tag, maybe that's why your SlimX displays the tag properly (assuming your SlimX can read ID3v2 properly).

Case 2 has a Lyrics3 tag (that's why the string "CSBEGIN..." as in "LYRICSBEGIN" appears).

As for why your SlimX doesn't display the tag properly, it could be lousy programming.
Maybe the SlimX searches forward in the last KB of the file for "TAG" (ID3v1 signature). Then it would find "APETAGEX" (APEv2 tag signature) and believe it's ID3v1. Had a similar bug in Frontah, where APEv2 could (in some rare cases) be mistaken for an ID3v1 tag.

The solution to your problem would be to not use APEv2 with MP3.

Case 1: APE, ID3v1
Case 2: APE, Lyrics3, ID3v1
Case 3: ID3v2, APE, Lyrics3, ID3v1

I'll assume that Case 3 displays correctly because there's an ID3v2 tag present.

The Lyrics3 tags present in Cases 2 and 3 are empty (tag is there, but contains no data).

As best I can guess for Case 2 (where it displays "CSBEGININD00000200CRC(...) - eXd") for some strange reason the ID3v1-scanning code is picking up the "TAG" signature (that should be present 128 bytes from end-of-file to indicate the presence of an ID3v1 tag) not from the ID3v1 tag, but as part of the APE tag footer (which starts with "APETAGEX"). The APE footer is 32 bytes long, filled with mostly non-text data. What's happening in your case is the phrase "TAG" in the APE tag footer is being picked up as the beginning of the ID3v1 tag, and the next 30 bytes are read in as the title (which would contain mostly non-readable characters), then the next 30 bytes are read in as the artist, which in Case 2 is most of the Lyrics3 tag (which begins with "LYRICS3BEGIN", and then the data field name "IND" (see here for Lyrics3 field names) and its data, then the "CRC" field name and its data. So you get "CSBEGININD0000200CRC0000839837" as the artist, and "EXÐ???Ž??????????€????????LYRI" (which might not display properly since it contains binary data) as the title.

Similarly for Case 1, it's picking up the "TAG" signature 29 bytes too early, so you get "ead" as the artist and probably "EXÐ???Ž??????????€????????LYRI" as the title.

So to me it sounds like the SlimX has defective ID3v1-processing code - instead of looking 128 bytes before the end of the file for "TAG", it looks a little before that (200 bytes maybe? It apparently doesn't go back far enough to run into the APE header, which in your examples is 332, 351 and 384 bytes back from end-of file.

I've got a SlimX (IMP-400) myself, and have been considering asking about this tag problem for some time.
Experienced it once and suspected the APEv2 tags added with foobar2000.
Would it be worth it to send an email to iRiver and ask if they can add APE tag support? I have no idea how difficult it would be. It might end up like their "upcoming" Ogg support.

As I use APEv2 tags with foobar2000 it's not an option to stop using them, so I need some kind of workaround. The solution I was thinking about, was to just remove them before burning a cd for my SlimX.

just an idea, wouldn't it be wiser (but perhaps more difficult to code), to add the RG to the Lame Tag

Not completely on topic, but I have seen Lame Tags disappear when the file is replay-gained using MP3Gain v1.0.0 with the v1.3.3 backend (I have not tested this with other MP3Gain versions.) I don't know if the Lame tag is actually gone, or if EncSpot just gets confused somehow (I don't know of another program to test and see if the Lame tag is there...) The only files I have see this problem occur with were files released by ripping groups with ID3v1 and Lyrics tags. Files made with RazorLame and Lame v3.9x do not seem to exhibit this problem. Snelg - if interested, I could send you a file that exhibits this symptom, although I can't upload it for obvious legality reasons .

I had this problem with my ChromeX (150).
My foobar2000 processed files' tags were displayed "EXÐ".
As my Jensen in-dash MP3 player has no problem, and I refused to ditch my Ape tags I found a workaround that works for me: In the iRiver settings I changed display info to "display filename". Now I have no problem (my filenames are always the same as the name of the song).

For what is worth...

i did the same thing, but I ended up missing tags
so now I use a batch for removing the APE2 tags, burn, then Rewrite the info from Foobar's DB

"Missing"? As in "extrañando"*?
Or what are you talking about?


*In spanish, "missing" has two meanings:
1) To lose/not have: "iRivers are missing one key feature: replaygain support"
2) To long for somebody/something: "I'm missing you, like the deserts miss the rain (yeah, it's lame, but it's all I could think of)

I have also asked this many times without reply.

The problem is that not all MP3 files contain LAME tag.
So he would need to detect if it's already in the file and revert to current method if it's not
or maybe add the tag if necessary.

Actually, Case 1 is the only mp3 ripped/encoded/tagged by myself. All the other ones are "scene releases" and I wonder why do they have Lyrics3 and ID3v2 tags, since they are forbidden in an "official" release...


You're right.
In Case2 SlimX displays "CSBEGININD0000200CRC0000839837" as the artist (like you said) and "EXÐ" as the title (just EXÐ).


For Case1, all the 107 MP3Gain'd files display the Title as "itle" (omiting the first letter) and no Artist.

emtee - the obvious answer seems to be this: try adding ID3v2 tags to some of the problem files.

westgroveg - the lame tag has space for track and album gain, plus peak value. But it doesn't have a defined space for an "undo" value, which is the most important thing that mp3gain needs to store. Plus, more importantly, what AstralStorm said!

snelg - I don't envy you!!!

Cheers,
David.

I think i'd rather remove the APE tags instead of tagging all the files with ID3v2... I don't trust ID3v2 and my system is very unstable right now (i'm having some problems with my motherborad) which can lead to a massive corruption of the files.

Let us wait for Snelg's reply. Also, some sort of "bugfix" for MP3Gain would be great

Edit: link

Ay, chihuahua!

Before we completely re-discuss pros and cons of the various tagging solutions (APEv2, ID3v2, LAME header), everyone refresh your memories:

http://www.hydrogenaudio.org/forums/index....=2&t=9692&st=25

My head is starting to spin.

It's true what they say about not being able to please everyone all the time...

There IS space in the Lame header to store undo values for mp3gain-like tools.

May I propose a combination? Why not allow the user to choose between storing the undo information in either an APEv2 tag, the extra space in the L.A.M.E. tag, or the "Comment" field in an ID3v1 tag. And then, rather than bothering with coding support to write ID3v2, simply add support for MP3Gain to read those values from an ID3v2 field (of specified name) should the user choose to use some other tagging utility - on their own head be it - to convert the "Undo" field to ID3v2 from one of those other, aforementioned types?

Several reasons for this:


[*] Lots of of us still do - and will - use ID3v2 tags. Hardware support is a strong incentive. And "read" support for ID3v2, if I understand correctly, is not as difficult to implement as "write" support.


[*] An ID3v1 tag is possibly the easiest to implement, and to remove. Thus, the ideal solution for those who would wish to use it for temporary storage of the "Undo" field, if they planned to transfer that data to ID3v2.


[*] Some of us deliberately disable the L.A.M.E. tag via the -t switch, and would resent the necessity of reactivating it for something which could just as effectively be stored elsewhere. (Some folks also prefer the L.A.M.E. tag for the information it is capable of providing. I'm not arguing its value one way or the other; I am simply offering viable situations.)


[*] Some of us also think APEv2 tags are not the most desirable format in the world, and would resent using them under any circumstances. Hey, Peter likes them and he's built a great audio player with the firm conviction that they are the best... but respecting his decision does not require one to agree with it. (Heretics, aren't we?)

Anyway, please take these comments in the spirit intended.

- M.

Why would you disable the LAME tag??

Emtee, can you try how your player displays tags if you change the order of them with Tag and command --force APE2 --force ID3 file.mp3.

Personal preference. I am not sharing my MP3 files; they are encoded for my own use, and I am well aware of what encoder and settings I used to create each one. Also, early on I ran into a couple of (probably poorly designed and now surely obsolete) hardware devices which had difficulty with L.A.M.E. tags, and upon learning that those functioned better without the tags I began disabling the tags by default. The way I encode my music doesn't affect anyone other than myself, but there are a few other people in the world who use that switch... which is why I considered it desirable to have a series of alternatives for storing "Undo" information, rather than simply forcing it to be included in the L.A.M.E. tag and thus forcing the use of said tags for anyone desiring the ability to undo an MP3Gain adjustment.

- M.

I think I've noticed something similar with my Pontis SP600. If I have encoded a mp3 file with id3v1 tags and used mp3gain (Linux console version 1.3.3), the Pontis fails to read the id3v1 tag on some files (like one out of twenty or so). I haven't thought of APE tags causing problems earlier, does this version of mp3gain add those?

Adding id3v2 tags to those files always fixes the problem - the player ignores the id3v1 tag if it finds an id3v2 tag. It indeed seems to have somewhat buggy id3v1 tag reading system.

Id3v2 tags, on the other hand, caused slight problems with my iRiver ChromeX - the remaining playback time indicator didn't work correctly with VBR files if there was an id3v2 tag, but it worked perfectly if the file only had a v1 tag. I wonder if this problem also exists with the SlimX? Anyway, this is rather minor, and for example the Pontis always shows playback times (even elapsed time) incorrectly with VBR files.

no, the SlimX displays the correct time on VBR files as long as they have the lame tag.

I tried this now and it made no difference on my SlimX IMP-400.

This is what I did:

Made 3 versions of the same album.
(1) Left is as it was
(2) --force APE2 --force ID3 *.mp3
(3) --force ID3 --force APE2 *.mp3

Tagger reported (1) to have ID3v1, APE v2.0 tags.
All of them displayed 'EXÐ' on my SlimX

Btw: I have not used MP3Gain on this album, but Replaygain added with foobar2000.

That might cause problems for other players out there. And it looks like the SlimX problem can be solved by using id3v2 tag for artist - title.

The beauty of the APE2 tags is the FooBar2000 compatibility
--
Ge Someone

you can get these tags too with the old ID3v2 plugin, it used to store the foobar especific settings in comments.

Neither the iMP-150 ChromeX nor the iMP-350 SlimX displays accurate timing and seeking information if a VBR MP3 contains an ID3v2 tag. The only way to get these devices to show accurate information is to make sure that the VBR MP3s contain only ID3v1 tags. I have tested this on numerous occasions with different firmware revisions (including the latest).

hmm..
that's weird.. I could swear...
that's why I don't use tags when burning MP3 cds.

Yes, I made the test. I repeated the previous steps:

1) Ripped a CD to .wav using EAC
2) Encoded the wavs to mp3 with LAME 3.90.3
3) Tagged the mp3s using ID3v1 with Tag'n'Rename
4) MP3Gain'd the mp3s using Track Analysis so they all sound the same volume (using latest version - 1.2beta)

Then, I tagged them using Tag.exe with the suggested command line. Here's the Tag.exe output:


etc...

I used the following encoding modes for testing:

track01 = --alt-preset standard
track02 = --alt-preset standard
track03 = --alt-preset extreme
track04 = --alt-preset extreme
track05 = --alt-preset 192
track06 = --alt-preset 192
track07 = --alt-preset cbr 192
track08 = --alt-preset cbr 192

SlimX wasn't able to correctly display the tags in any of the files. In fact, it didn't displayed tags at all, not even ID3v1, showing only the filenames.

What was the purpose of this test? To see if SlimX could display the tags if the APE tags were placed before the ID3 tags?

The behavior of tag reader seemed so strange that I thought your player would scan for the tags from the beginning of the file searching for tag identification word "TAG". The line I asked you to test placed ID3v1 tag before APE tag to see if the assumption was correct. Seems that it wasn't and the player has very broken ID3v1 reading, nothing else.

This is fascinating... I rip with EAC, encode with RazorLame/Lame3.90.3/Alt-Preset-Standard, adjust with MP3Gain, and then do the tagging last, with MP3 Tag Studio. I use ID3v1 and 2.

My RioVolt SP 250 running iRiver iMP-250 firmware has no trouble reading the tags. But maybe that's because it's just reading v2 tags.

Haha but the iRiver firmware does have an annoying problem with not getting the alphanumeric file order quite right.

Really? I am also using the iRiver iMP-250 firmware v2.20 on my RioVolt SP-250, and have never noticed any difficulties with the alphanumeric sequencing. Are you relying solely on the tags to supply this, or are your files also named in the order?

For reference, the most accurate way to guarantee files will be displayed/played as desired is to name them sequentially, build your ISO such that they remain in the proper order, and set the iRiver player to sort files by their physical address on the disc (a feature which was added in the 2.20 firmware). You can use something like CDMage to view the LBA of your files within the ISO, in order to verify their order before burning your disc.

- M.

iRiver iMP-350, sorting fine too.

@ Neo
perhaps it's time for an upgrade.

Question; does something saying EXd show up instead of whatever is supposed to? I've never used my SlimX without MP3gained MP3s so I'm not sure. This confuses me.

Also, would allowing foobar to apply replaygain using the diskwriter plugin for converting to MP3 make a difference with this? Would stripping the ID3 tags and putting them back on with the program I use for it make a difference? If not, I just won't use MP3/replay-gain for now.

Edit; upgraded to Firmware version 2.20 for the IMP-350, the ID3 tags show flawlessly now, no EXd, ID3 tags look fine.

Yes.
Instead of the original tag, SlimX displays "CSBEGININD0000200CRC0000839837 - EXÐ" as the Artist - Tracktitle. This occurs only if you tag your files with ID3v1 and then MP3Gain them. MP3Gain (1.2beta) stores the undo info in APEv2 tags, leading the poorly designed SlimX tag system to display erroneous info (garbage), since it doesn't support APE tags.
This may be solved by adding ID3v2 tags to your files - SlimX will ignore all the other tag headers and will display the ID3v2 tags correctly - or by removing the APEv2 tags in MP3Gain - just select the files and choose "remove Tags from file".



Well, I don't use Foobar neither Foobar's replaygain, but since the problem is related with APE tags, if foobar don't add any kind of undo info into APE tags, SlimX will read the tags properly.

Edit: typo

btw, what's wrong with the Font sizes in this board? i can't specify my font size...