similar to: newbie questions

Adam Rosi-Kessel wrote: > Yes, it was Mediamonkey. They claim that it was due to a bug in vorbis > libraries. All software has bugs, but this explanation doesn't really add up. libvorbis is the codec. If they had blamed libogg, which does the container, then yes, that would have been a believable explanation :-). Erik --

So before i knew better, i encoded a lot of my CDs in flac and added id3 tags (they worked, so great!). I know i've seen mention of others doing this; anyone gone to the trouble to write a tag conversion tool? Shouldn't be too tough, but i'd rather not reinvent the wheel. danno -- dan pritts danno@umich.edu 734-929-9770

I have over 1,000 ogg vorbis files that are no longer playable or editable. I believe the main cause was a MediaMonkey plugin that automatically fetched album art and added it to the header. The plugin itself just uses the generic MediaMonkey metadata facility, but something happened -- perhaps when the album art bitmap image was too large -- that caused the files to no longer work.

> Is there any way to understand exactly how it is invalid? I can replicate > this corruption simply by adding large album art to any ogg file with the > latest release of MediaMonkey. The second page is corrupt. The basic structure looks correct, first guess would be bad checksum. I'll look more closely in just a bit. This might explain why some players might accept it--- if

Conrad Parker wrote, on 6/20/2009 10:24 PM: >> How about another approach -- is there a tool that will verify the page >> checksums? oggz-validate doesn't seem to do this. If the page checksums >> are okay, then doesn't that suggest the streams are also recoverable? > If the page checksums are bad then the page will get rejected by > libogg, and oggz-validate

Adam Rosi-Kessel <adam at rosi-kessel.org> wrote: > So I've written a script to do the following: ... I have got lost. Did you manage to identify the rogue software that corrupted the files in the first place? In the greater scheme of things, fixing this (prevention) is more important than repairing the files (cure). Regards, Martin -- Martin J Leese E-mail: martin.leese

After experiencing these symptoms through many of the release candidates, we've been at v1.0.0 now for a few weeks, and they're still there. Perhaps a config issue with my setup (mbox locks?). It's really too disrupting to continue using this way. I've included symptoms, client info, mta info, log entries and config file. What other information can I provide? Please

I mentioned sub-tagging in an earlier post. Here's a more in-depth mail on what i thought of. One of the debates going on here are whether ARTIST is worthy of life. Another is whether the average user will bother filling in the detailed info Jonathan wants. Of course, all tags are optional, but nevertheless we should have a tagging-system that pleases _the_users_, that is, everybody: 1.

Hi all - I've just finished building flac in the "darwinports" environment on MacOS 10.3.9. The port maintainer (i've cc'd him) had disabled the xmms plugin build. I wanted that, so I changed the portfile and built locally, yada yada. I've run into three problems, only two of which I've seen reported in the list archives here. 1) configure doesn't properly

Vorbose -v reports the following for the beginning of the file: INFO page: Capture pattern OggS, format version 0 Flags: first page of logical stream Granule position: 0x0000000000000000 Stream serialno : 0x490f5cff Sequence number : 0 Checksum : 0xee9c02b9 Total segments : 1 Total packets : 1

Adam Rosi-Kessel <adam at rosi-kessel.org> wrote: > I finally got something like an explanation from the Mediamonkey > developers. Here is their explanation as to why MM corrupted my files: > > > the problem was caused by the fact that Vorbis library uses alloca() > > function on several places, which allocates memory on stack. We > > changed it to alloc() and

A month or two ago I sent an email to this list proposing to expand the list of "standard" tags for Ogg Vorbis. No tag would be required, but if you wanted to encode certain types of information about a file, you could use a standard tag. I went through the whole discussion, and revised my proposal in light of all the comments from everyone. Here is the updated proposal. This

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

I am in a precarious spot.... I run centos 4.0. I upgraded my mod_perl RPM to mod_perl 2.0.1. CGI.pm 3.10 (3.05 comes with centos 4.0) fixes some namespace issues with mod_perl vs mod_perl 2.0.1. I need to upgrade to it to 3.10. Yet that file belongs to the perl rpm that comes with centos. What do people generally do in this type of situation? Do I need to compile a new perl just to upgrade

>> symptoms: >> 1. Coming back to the idle client, and clicking on a newly arrived >> message, often a long delay (seems like minutes, sometimes) will >> occur before the message loads from the server. >> 2. Sending messages, as often as not, the client will stall, >> sometimes indefinitely, on "copying message to sent folder". >> >

Interestingly, i just posted to the list a similar SPEC file. look at the thread on CGI.pm. I've attached my spec file for "fakejava" as well. It was a lot of trial and error to make it work. None of the documentation I could find was for modern versions of RPM, and IIRC the documentation i did find for older versions was incorrect somehow. I think I had to specify a source

-----BEGIN PGP SIGNED MESSAGE----- [ Sorry for sending this twice; I sent it to the vorbis-dev list by mistake. ] The ALBUM, ARTIST, TITLE, and TRACKNUMBER tags aren't sufficient for classical music. MP3 muffed it, but since Vorbis is so flexible, I'd like to propose that ogg123 recognize and display the following optional tags, instead of giving an error message that it doesn't

-----BEGIN PGP SIGNED MESSAGE----- [ Sorry for sending this twice; I sent it to the vorbis-dev list by mistake. ] The ALBUM, ARTIST, TITLE, and TRACKNUMBER tags aren't sufficient for classical music. MP3 muffed it, but since Vorbis is so flexible, I'd like to propose that ogg123 recognize and display the following optional tags, instead of giving an error message that it doesn't

Hi, (I was discussing this with Adam earlier today, and he has also mailed vorbis at xiph.org about this issue in March). This sounds like it needs a new tool specifically for fixing broken Ogg files. Suggestions so far (tried by Adam, or suggested to him in email/IRC): * oggz-sort, hogg sort These rewrite the file, sorting the pages by presentation time. This usually fixes muxing problems,