I found this excellent site with information on mp3 encoding, and will be using his recommendations for re-encoding my CDs with VBR thru lame (currently they're lame 160k CBR, I'm re-encoding just to have a fresh start with a slightly higher, VBR bitrate, as well as more useful ID3 info).

http://users.belgacom.net/gc247244/index.html

However, this person is somewhat opposed to ID3 v2 tags, according to the following page:

http://users.belgacom.net/gc247244/index.html

I was wondering what others thought of his stance. Obviously going without ID3 is not an option on the empeg, but the lack of gapless play with ID3 v2 made me think..

- reid

The only reason to avoid ID3v2 is that some (older) programs don't understand the format. Newer programs which do understand it (including, for instance, Emplode, the car player, and HSX-109) have no problems with it, compared to using ID3v1. Gapless playback is a complete red herring; it is not affected (in any of Empeg's software) by use of v1 or v2.

IMO, v1's restrictions on tag lengths make it unusable -- I only ever use v2 -- but then, I've got a large Orb collection, and they tend to go in for long track names.

Peter

His recommendations for LAME settings have worked very well for many people on this board and elsewhere. They are well thought out and well researched, and they work.

That said, his anti-ID3 stance is, in my opinion, completely retarded. From the discussion I've read on this board and others, it seems that most people experienced in MP3 usage think that his position on the matter is that of a complete nutjob.

It's too bad, because it hurts his credibility on the encoding settings. I think it's a big factor towards people moving their efforts to tweak the --alt-preset settings instead of the --r3mix setting.


-Aaron

The sites you posted are r3mix's. The correct proper URL is www.r3mix.net.

Unfortunately, he doesn't know what he's talking about when it comes to tags and current-generation software/hardware. I use a modified version of his LAME parameters, but newer versions of LAME (3.91) feature some tweaks by dibrom that surpass the arguments found in the r3mix LAME 3.90 settings.

Take a BIG grain of salt when reading r3mix's site. He has valid points, but sometime's it's clear he doesn't know what he's talking about.

Bruno

While older programs won't understand the format, they shouldn't be affected by it, either. ID3v2 is designed so that programs that don't know how to deal with them will also see them as non-audio garbage and just skip over them.

My biggest gripe about ID3v2 is that they're at the beginning of the file. With ID3v1's being at the end, you can remove them from a file while it's playing and it's trivial to do so and very(!) fast. I wrote a tiny C util to remove ID3v1s (before v2 was around) because their short fields made them worse than having no tag at all. So with thousands of songs without any tags, I don't like having the occational ID3v2 slip in there. Removing v2 tags is a pain since you have to copy the whole file. It takes a long time and you can't remove it from the file you're playing.

I'm sure very few others share my complaints.

You could also place the ID3v2 tags at the end of the file, if you wish. It's just as valid there as at the beginning.

Really?! I didn't know that. I've never created any v1 or v2 tags. The only v2 tags I've had is from a couple downloads and all of them have been at the beginning.

Unfortunately, I'll bet that there are a lot of implementations that assume that they'll be at the beginning, but the specification explicitly allows for them to be anywhere in the mp3 file as long as it doesn't interrupt an individual mp3 frame.

Headers and tags belong at the beginning of files, not at the end. This would be a big minus for V1 and a plus for a normally-implemented V2. Why you'd care about stripping tags while playing the files is beyond me.

If you're concerned about stripping tags you should be using a batch processor. Doing anything tag-related manually is always a pain in the butt.

I've got nearly 6000 tracks right now. If I had been downloading, I suppose I could have many more than that. They're all tagged exclusively with V2. My filenames and folder structure also specify the basic tag information (and I have tools that can go back and forth, generating tags from folder/files and/or generating folder/file names from tags).

I have yet to see any compelling reason not to have tracks properly V2 tagged. Just words of panic from people who don't know any better (I'm not putting you in that boat ) Tags are one of the big pluses of the storage format.

Bruno

Like I mentioned before, it takes a long time to remove tags from the beginning of a file. Of course I do all this via batch processing. With tags at the end, all that needs to be done is truncate the file. This takes a millisecond or two. To copy a 5 meg file and takes a couple orders of magnitude longer! When you're processing thousands of files, even if they all have tags at the end, it can be done in a couple seconds. But expect it to take hours if the tags are at the beginning.

This sounds like a bit of a circular argument: ID3v2 tags are bad because they are difficult to remove, and you want to remove them because they are bad.

Like I mentioned before, it takes a long time to remove tags from the beginning of a file. Of course I do all this via batch processing. With tags at the end, all that needs to be done is truncate the file.

Of course, adding tags at the beginning is hard work too. Someone on linux-kernel was saying that in 2.5 timeframe, they'll be extending ftruncate() so it works at arbitrary points in the file. Even if that only turns out to be at block boundaries by block amounts, that would stil r00l.

Peter

Create tags when initially encoding music. Pad tags slightly. Now changing the tags takes no time at all.

The files aren't there for the pleasure of playing with them, adding, removing, adding, removing. They're there for the content they provide. And when accessing, it's a lot easier more straight forward to read off the beginning of the file than it is the end.

The biggest complaints with v2 come when people are setting them up for their own very specific use and then end up sharing the files. So you get all the Napster and WinMX leeches complaining about them. I'm encoding all my own music for use on my own player.

Bruno

I'll have to agree with Bruno on this one. v1 tags are worthless. Winamp, empeg and just about everything I know of supports v2 tags so that's all that matters to me.

I know it sounds circular, but it's not. I tried to explain all that in the beginning.

If ID3v2 had been around when I mp3ified all my CDs, I'd have used it. But it wasn't so I have thousands of songs without it. I'm not gonna go back now and add 'em since I've already got a consistent way of storing the fields I want as file names.

By no means am I trying to convince anyone to do things the way I do. I think ID3v2 is a better system that what I use (file names), but it just arrived too late for me to use.

I know there's automated tagger to copy data from my file names into v2 fields, but I'm too entrenched in using file names. I've written many scripts to automatically sort my songs, update my checklist and rewrite my playlists for songs that have moved that I'm not interested in changing now... I'll just keep doing my own thing

Are you planning to move the majority of those songs to the empeg? Are you going to write your own script to munge the empeg db?

Now that would be a useful util. Esp. if it could be easily run from the empeg itself. Right now the options in emplode are limited to straight manual and using macros from a third party application. Of course this is to modify anything not automatically read or present in the original file tags. I'm still keeping my fingers crossed for seeing a scripting solution from Roger - whenever that shows up and in whatever form. For the meantime I make sure tracks I import contain full tags. To do tagging of playlists I have made Macros for the keyboard macro program "OnHand"

Bruno

That would be a useful util, but I don't know enough to be able to do it. I liked Roger's comment about having a configurable import thing in an upcoming emplode. It sounded like it would do what I want so I'll prolly just use that