I am totally in the dark with regards to OGG vorbis files. Will anyone here take a few minutes to point out what the advantages OGG files have if any over mp3? I downloaded a few and noticed higher VBRs with slightly better audio over mp3 in some cases. I thought I'd ask here since I haven't posted in a while and also because you people on this board are generally more knowledgable about these things.

Thanks.

That's right, OGG files deliver a higher quality for the same file size.

However, if you create your MP3s at very high bit rates (such as 256 or 320) using a good encoder, then you won't really be able to tell the difference between an MP3 and an OGG.

Since, on the empeg, I can use any size hard disk I want, the quality-for-space tradeoff of OGG versus MP3 is therefore irrelevant to me. So, in terms of the empeg, the differences between OGG and MP3 are:

- OGG files require me to run an unstable alpha version of the player software if I want to use them.
- OGG files do not have as many software tools available to organize, tag, and edit them.
- OGG files work on very few other players, thus limiting my ability to move my songs among various devices and computers.

So for me, MP3s still win hands-down.

Tony's analysis is accurate, but I'd value his conclusions slightly differently.

I've got 3k oggs on one player and 15k on another (and constantly uploading more files to both), and was running v3a7 for over a year until just recently when I upgraded both to v3a8. I either listen to a specific album or a down-down-down shuffle, so I'm not doing any advanced playlist management. I encode at -q 6, nominally 192 Kbps.

There have been no real problems with the "unstable alpha version of the player software". All of my major issues seem to have come from the different ways that emplode and jemplode manage the files. I had a real problem that came from a file deletion action that created a hole in the fid numbering that never got filled in. There are a number of minor issues related to the alphaness of the software, like songs being marked and such, which may be too annoying for some people, but hasn't bothered me. YMMV.

There are enough tools to organize, tag, and edit ogg files. foobar2000 does almost everything anyway, and is as high quality software engineering as the stuff from our beloved Empeg Towers. The tools are different than what you might be using for mp3 files, true, but there's enough of them out there.

Ogg files don't work on very many players =compared to mp3= but there are a lot more ogg compatible players than you think. Additionally, if you're encoding your mp3's at 256+ Kbps you're not going to get many onto most hardware players anyway.

(Vorbis has support for bitrate peeling where you can on-the-fly make a copy of the file at a lower bitrate, but nobody's built a real tool for it yet. Theoretical advantage.)

At 128 Kbps ogg vorbis is significantly better than mp3, but at higher bitrates both files quickly reach transparency, and the difference in size at that point is much less significant. There are very few people who can honestly (in a double-blind test) tell the difference between either at 256 Kbps and the original source material. There are many who claim to, but don't use a valid test methodology.

Mp3 maxes out at 320 Kbps, ogg vorbis can go higher. Some hardware players can only decode ogg vorbis up to a certain bitrate.

Ogg vorbis is more computationally expensive, but there have been a number of improvements in the tremor implementation and such over the last few years so that this factor has improved. In any case, a mk2a has memory and cpu to handle this.

Ogg vorbis is natively gapless, if that matters to you.

Ogg vorbis is open source/patent-free unlike mp3, =if that matters to you.= (Yes LAME is open source, but that's just one encoder not the standard itself. Someone somewhere is paying royalties on mp3 technology even if it isn't you.)

The tag capabilities and standards of ogg is =so much better= than mp3, though this probably is not be an issue to most people, but it is true.

Ogg vorbis files are harder to share because your friends probably can't listen to them, and certainly not on an iPod. (Transcoding is bad even though we all do it at times.)

So there is no objective best. Both have quirks and frustrations that may or may not matter to you.

I think I stayed pretty objective about all that, at least I tried to.

--Nathan

Well, there's this... to start with.

But hey, I could be wrong too. So don't read this as the beginning of a pissing contest or anything.

1. All of my tags end up on the empeg properly, so it least works that well.

2. Given who and where tag related software gets developed, I'm not sure that a standard would actually be useful. Everybody is doing their own thing anyway.

3. The more esoteric a tag is the smaller the group of people who would use it are, and the less likely that some mainstream developer is going to support it anyway.

4. Anyone can tag files improperly, even with the basic tags like artist and title, so there's no enforcement of the content of a basic tag anyway, so how can there be enforcement of adcanced tags? If the tagname is "BeatsPerMinute" you have to blame the person who put wrote the tag not the standard if it's not correct.

5. Ogg tags do need to be UTF-8 text strings rather than BLOBs, but the spec says "arbitrary metadata belongs in a separate logical bitstream (usually an XML stream type) that provides greater structure and machine parseability."

6. So what really happens is that tagging gets done to meet the capabilities of whatever player the person is using. That's the real bottleneck, and most of the time when someone pushes the boundries they end up with some crappy hack that works but doesn't scale in any way other than what the hack was supposed to solve.

7. ID3v2 is not part of many codec standards (like AAC not in a mp4 container) but folks go out and write taggers and players to violate the specs just because they don't know any better and propagate the problem.

In the end, I don't think that there is a single solution for everybody, and I guess the decision comes down to personal philosphy.

--Nathan

I don't intend this to be a pissing contest at all. It's just that I so often see people say that Ogg tags are so much better without any basis for that judgement. Again, I'm not intending this to be a pissing contest, but lemme respond point by point.

Quote:
Well, there's this... to start with.

That's actually part of my problem. That's an official page put out by the Ogg folks, the people in charge of the spec, and the best they can say is "Below is a proposed, minimal list of standard field names with a description of intended use." Umm, how hard would it have been to just say "These are the defined fields. More may come, but these are the basic standard." The fact that they're "proposed" within the standard that they defined themselves means that there's no official list.

Quote:
1. All of my tags end up on the empeg properly, so it least works that well.

This is a very, very, good point. My problem with it is basically along the lines of the fact that the developers had to assume that "proposed" meant "official".

Quote:
2. Given who and where tag related software gets developed, I'm not sure that a standard would actually be useful. Everybody is doing their own thing anyway.

I don't even understand this point. Everyone's making up their own tags, so there's no point in trying to come to a consensus about what they should be? The ultimate result of that sort of thinking is Oggs floating around that have "BEATSPERMINUTE" tags and others that have "BPM" tags and others that have "BEATRATE" tags, etc. ad infinitum.

Quote:
3. The more esoteric a tag is the smaller the group of people who would use it are, and the less likely that some mainstream developer is going to support it anyway.

But no mainstream developer is supporting it now, not because the audience is too small, but because they have no target to shoot for. Define a standard and then let the developers decide if it's worth their time to implement that part.

Quote:
4. Anyone can tag files improperly, even with the basic tags like artist and title, so there's no enforcement of the content of a basic tag anyway, so how can there be enforcement of adcanced tags? If the tagname is "BeatsPerMinute" you have to blame the person who put wrote the tag not the standard if it's not correct.

I don't understand how the fact that people tag things incorrectly is an argument against having "advanced" tags. The ultimate result of that thinking is "People can't even tag Track Name correctly, so why bother having a "Track Name" tag at all since it's likely to be wrong." Followed quickly by "Why do we have this tagging structure now that we've gotten rid of all the tags?"

Alternately, what you might be saying is that if someone writes a "BeatsPerMinute" tag when it's, in fact, supposed to be "BPM" (or something like that) then it's the user that's wrong. If so, that would be a very good point, if there was any tag that was defined as containing BPM information, but there's not. The problem is that you can legitimately put BPM information in a tag named "BPM" or "BEATSPERMINUTE" or "BEATRATE" because there is no standard. You could even put it in a tag named "PERFORMER", since its use is only suggested. WIthout standards, there's no way for anyone to say "yes, this is definitively BPM information."

Quote:
5. Ogg tags do need to be UTF-8 text strings rather than BLOBs, but the spec says "arbitrary metadata belongs in a separate logical bitstream (usually an XML stream type) that provides greater structure and machine parseability."

I think that this refers to the idea that such tags should be encoded still within the same file, but as a logically separate part. As such, failing to call them tags is semantics at best. At the same time, they are arbitrarily limiting themselves.

Quote:
6. So what really happens is that tagging gets done to meet the capabilities of whatever player the person is using. That's the real bottleneck, and most of the time when someone pushes the boundries they end up with some crappy hack that works but doesn't scale in any way other than what the hack was supposed to solve.

But within ID3v2, the boundaries are way out there and well defined. You can define arbitrary tags if you want to with whatever data you want to put in there. WIth Ogg tagging, it's all boundaries. Even the notion that TITLE is the track name is going out an a limb, albeit a very sturdy one.

Quote:
7. ID3v2 is not part of many codec standards (like AAC not in a mp4 container) but folks go out and write taggers and players to violate the specs just because they don't know any better and propagate the problem.

Nor is Ogg tagging part of many codec standards. You're saying that ID3v2 is worse because it's not universal while touting Ogg tagging, which is also not universal.

Quote:
I don't think that there is a single solution for everybody,

But there has to be. The fact of the matter is that you're not going to be writing the software that plays your Ogg files. Changes are that someone else is going to write them. And if they need BPM information, for example, then they're going to have to make up a tag on their own to hold it. But then maybe you want to play your Ogg on another device that also wants BPM information. But they've also come up with their own tag, which is not the same as the first developer's. So now you have to duplicate the tag. Then you find that you estimated BPM incorrectly. Now you've got to update two tags. But then you forget that the first developer wants it as a UTF-8-encoded integer while the other wants it as a decimal fraction indicating time between beats. And then another developer comes up with a BPM tag that indicates BPM at different points in the song. You get my point, I think. And you may be thinking, okay, but that's just small amounts of data. What happens when we start talking about images embedded in the tags and you've got three different ones?

IMO both ID3 and Ogg tags are flawed in different ways. My least favourite ID3 feature is that the codepage of the text isn't defined -- or rather, that it is defined in the standards, but that everyone ignores it and writes text in their local 8-bit encoding and marks it as ISO8859-1. (Whereas the standard says that such tags should be written as UTF-16 -- somehow the magic word Unicode scares people off from using it. I mean, mbstowcs() on the way in, wcstombs() on the way out, how hard can it be?) This means that tag-reading software has no way of telling exactly which characters are meant, unless the tags happen to be read on a system with the same codepage as the writer. Ogg tags are required to be UTF-8, so there's no ambiguity.

My least favourite Ogg feature is that you have to rewrite the entire file when the tags change, because if the new tags cross a page boundary you need to rewrite the page numbers on all subsequent pages. Retagging an Ogg file takes hundreds of lines of code even once you've written the actual tag block. This in turn means that answering the question "are these two files the same apart from the tags?" is decidedly non-trivial.

Peter

Yeah, I didn't mean to imply that ID3v2 is perfect by any means, but given the fact that they've engineered something that works with an audio spec completely out of their control while the Ogg folks had 100% control over both sides plus the integration and came up with something that's fairly mediocre in the real world (especially when it would have been so, so, easy to have resolved the biggest problem) puts the ID3v2 folks ahead in my book. Certainly they haven't done a worse job.

And the fact that developers don't follow the standard is hardly the fault of the standard except to say that the standard could have been less convoluted.

Hmm...lot's of great information in this thread. I think that the only reason I'd like to use OGG files at this point would be for mix discs in order to take advantage of the gapless playback mp3's come up short on. A while ago I remember reading about ripping a whole cd as one track and using specialized software that would split tracks at the 'frame' closest to the intended track split time. I couldn't find it or whatever at the time so I just accepted the teeny gaps in the playback. I know that the 'solution' mentioned here isn't an actual solution because all that is really acheived is a minimization of the gaps presence.

On a different note, would anyone care to explain how an album cover gets embedded in an mp3 and if you think it's worth the larger files sizes? I went ahead and started to embed 300x300 pixel average jpgs into all my files recently because when software that supports the feature becomes more mainstream they will be there. I use Tag&Rename to tag all my files and for some reason when I remove the album covers from the mp3s the file sizes don't decrease. Why does this occur? How do I correct this?

I have also noticed that the preferences for T&R include the option of 'writing Unicode data into ID3v2 tags' and don't know what that really means.

MP3 files have no data in them beyond audio data. Folks have come up with schemes to attach metadata to them. The most recent one is called ID3v2. It (usually) comes at the beginning of the file so as to work better when the MP3s are streamed. The pictures you embed in them are placed in that structure at the beginning of the file. The main drawback to putting them at the beginning of the file is that it makes them hard to edit. If it was at the end, you could just chop it off or add more space, but, at the beginning, you have to rewrite the entire file. The folks who developed ID3v2 recognized this problem and decided to work around it by allowing for there to be blank space in the ID3 tags. Blank space is usually added at creation time so that new tags can be added easily. This also means that when you delete a tag, it can just be marked as blank space so that you don't have to rewrite the whole file. This is why your mp3s aren't getting any smaller. Your tagging program might have an option somewhere to compact the tags. Look for that. It may well be under a different name than compact, but it ought to be there.

Unicode is a method by which any known alphabet can be encoded, from English's to those of accented European languages, to Greek and Cyrillic, to the massive alphabets of Oriental languages. The specifc method used in ID3v2 (except the most recent version, which is not widely implemented yet) would result in doubling the space required for English words. If you don't need it, I wouldn't advise using it.

Many thanks for that explanation.