Hey all,
Have a question: You know, why Ogg Vorbis files need so long to Tag or to rename with tag?
mp3s are average. Mpc really go fast but Oggs are so lame
Thats the only disadvantage of this format.
thanx, Duke
Hey all,
Have a question: You know, why Ogg Vorbis files need so long to Tag or to rename with tag?
mp3s are average. Mpc really go fast but Oggs are so lame
Thats the only disadvantage of this format.
thanx, Duke
How can they be slower? Are you using some kooky software or something? What is your setup. They are speedy for me.
Ogg comment header is located at the beginning of the file, editing it with vorbis libraries means that whole file must be rewritten with new contents. On a 3MB file this means that about 16000 times more bytes must be written compared to tags that are located at the end of file.
If ogg ever takes the big step into the file sharing programs and/or Usenet, there are one advantage and one disadvantage with the tagging system.
Disadvantage: If for some reason the transfer is interupted, you cannot tell by the tags if the file has been interupted. This is the case for mp3s and id3v1 - a quick look at the tags of an album and you can spot the incomplete tracks immediately.
Advantage: You actually get the tags even if the transfer is interupted.
So with this in mind, I'd prefer both id3v1 and id3v2x in mp3's published on the Internet. But that might just be me.
Ogg comment header is located at the beginning of the file, editing it with vorbis libraries means that whole file must be rewritten with new contents. On a 3MB file this means that about 16000 times more bytes must be written compared to tags that are located at the end of file.
I don't understand why "padding" is not implemented with oggenc yet. It has been described how to do it - around 10 lines of extra code if I'm not mistaken. Then editing tags in ogg files would be just as fast as with any other sort of tag.
Maybe you (or someone else who can compile oggenc) could make a custum version? I'm pretty sure it would go in the main branch soon enough...
I'm not so good with C myself so I haven't managed to compile oggenc yet so I wait for someone else to do it... But here is what I suggest to change:
After this line in encode.c:
vorbis_analysis_headerout(&vd,opt->comments, header_main,&header_comments,&header_codebooks);
Add:
header_comments.packet = realloc(header_comments.packet, header_comments.bytes + 1024);
header_comments.bytes += 1024;
At least the idea on how to do it should be clear.
Oggenc2.1 is now available at Mirror 1, below. It incorporates the following additional command line option:
-p, --padding n Number of kilobytes of padding to provide in comment
header for post-encoding tagging. (0 - 4 permitted)
The requested space is zero filled.
What about having it defult to 0.25? Would this be a problum? Can it take a decimal value?
thanks in advance
Updating Ogg tags in Media Jukebox seems very fast, so by default it seems there is SOME padding and it is NOT rewriting the whole file.
Question is....will extra padding keep whatever tag editor from a whole file rewrite? If not then there isn't much point in it.
Why did Xiph put tag info in front of the file? Behind like in ID3v1 seems more logical.
Xenno
There is no padding by default, but if your new tag is smaller than what was there before obviously you don't need to rewrite the whole file. When you add padding to the file you won't have to rewrite it even when the new tag is bigger.
I believe that it was because ogg vorbis was heavily focussed on streaming, and therefore the header should be the first thing to arrive.
Also, part of that focus meant that it is possible to put extra headers in the stream throughout, meaning the tags can update while still playing a stream.
Seems like a good way to do it to me. Problem is update time (which may be resolved by using padding).
To be honest, I can't actually see where the logic of putting a stream header at the end of the file steps in. That is just me of course; I am not renown for my logic
gnoshi
What about having it defult to 0.25? Would this be a problum? Can it take a decimal value?
thanks in advance
I can pretty much make the
unit of padding( ) to be anything you like, but if I'm going to change it, let's do it once, OK?
How about I make it units of 128bytes upto a maximum of 5kb? Does anyone have any other ideas about this?
How about I make it units of 128bytes upto a maximum of 5kb? Does anyone have any other ideas about this?
Ye gods, don't make us do any more math than we already have to.
Bytes would be fine, for those that really want to have something exact. KB would also be fine, because who's really worried about 512 bytes of padding after a few MB anyway (and if you are, why)?
It could even be bytes, but multiplied by 1024 if the last character is a 'K' (or 'k').
Is adding padding going to affect gapless playback as it has with mp3?
Or has that already been addressed? B)
Only if your padding is large enough that it takes longer to seek through than your audio buffer can handle. In other words: Don't leave enough space so you can uuencode a 1200 dpi scan of the CD cover and you should be fine.
Disadvantage: If for some reason the transfer is interupted, you cannot tell by the tags if the file has been interupted. This is the case for mp3s and id3v1 - a quick look at the tags of an album and you can spot the incomplete tracks immediately.
There's something called EOS flag... when the last frame of an ogg file doesn't have this flag set the file isn't complete...
You can verify this with ogginfo for instance...
BTW this is
not vorbis specific
Maybe a function to verify the file can be added to the player plugins
How about I make it units of 128bytes upto a maximum of 5kb? Does anyone have any other ideas about this?
This sounds fine, lets just make it default to 2 (256bytes), that way if you have only a tag like "track 1" you can replace it with album, artist and, track w/o re-writing the file.
If ogg ever takes the big step into the file sharing programs and/or Usenet, there are one advantage and one disadvantage with the tagging system.
Disadvantage: If for some reason the transfer is interupted, you cannot tell by the tags if the file has been interupted. This is the case for mp3s and id3v1 - a quick look at the tags of an album and you can spot the incomplete tracks immediately.
Advantage: You actually get the tags even if the transfer is interupted.
So with this in mind, I'd prefer both id3v1 and id3v2x in mp3's published on the Internet. But that might just be me.
The ogg file header contains information that can tell you if it is an incomplete stream. Just run ogginfo on the ogg file, and it will say "possibly incomplete file"..... So you don't need to tell by the tags.
John33, is there any program out there that can add padding to an already encoded file ?
John33, is there any program out there that can add padding to an already encoded file ?
None that I know of.
Hmmm, perhaps someone could persuade peter to add it to foobar ?
Why cant the tags be anywhere in the file, like for matroska, so this decision is left to the app making them ? Is there any technical reason to not allow that in Ogg ?
why would anyone put something designed to be changed in the worst spot for changing? "cuz I love id3v2"
Metadata isn't "designed to be changed". I write my metadata once on average.
if you say so. heh.
Metadata isn't "designed to be changed". I write my metadata once on average.
...so good to see we have hawkeyed young men who never doubts or falters....
what crossed my mind when he said that was "then why allow it to be edited?" heh. "Because freedb is never wrong, always picks the correct CD, always has the correct spelling, and if you want to edit it that data you should be hung! There is never any reason at all, no possible situation or scenario, where you should be in need of editing that data!"