On Thu, Aug 28, 2003 at 03:09:07AM +0200, Sebastien Cevey wrote:> > Here is a simple recipe to reproduce the problem (I do not say bug for > I'm not sure it is one) : > > $ # Let orig.ogg be the original ogg file > $ vcut orig.ogg part1.ogg rest.ogg 1000000 > $ vcut rest.ogg part2.ogg part3.ogg 1000000 > $ xmms part?.ogg > > part1.ogg and part3.ogg are "searchable", but part2.ogg isn't. > > It seems like the file containing the beginning and the end don't have > the problem, but the middle files do.I found the same problem. Suggest using py-ogg to diagnose this, since vcut works on the Ogg layer (I dont think it even works with packets). Basically, vcut works on the principal that granulepos (a header field) specifies the last sample that's suppost to be decoded. If it's a negetive number, it means "skip this number of samples". It's the latter that this problem is caused by. When you cut orig.ogg into part1 and rest, part1 is the first chuck of the file up to a certain granulepos with the last page's granulepos set to the cut point. rest has the header pages (page 0 and 1) followed by the last page included in part1 followed by the remaining file. Yes, there is a 1 page overlap. The first page of rest.ogg has a negetive granulepos equal to the cut point minus the origional granulepos of that page. Pretty simple, works good. The confusion comes from when you use vcut to cut a file that's not "origional". Yes, the tail will cut correctly, but the first part of the remainer will always be messed up. I do not believe this to be a player problem, since the granulepos's seem mangled, it appears to be an issue with vcut. So there's two ways you can work around this. First, you can always cut from the origional, but that limits you. The other thing you can do is use a python-based program to cut based on granulepos. Just keep the first two pages in memory and go through chopping out whole pages and placing the page ranges in a file after the first two header pages. You don't have to even do anything to these pages, it's legal to skip granules/pages in the beginning of a stream. If you want to paste these together you will need to change the serialno of the bitstreams, treating the different segments as chained bitstreams. I hope that's enough info. If you need help using the python tools I'd be happy to provide more assistance on irc.xiph.org in #Python <p><p> -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis/attachments/20030827/20e9a294/part-0001.pgp
Hello I have experienced some problems with vcut (media-sound/vorbis-tools-1.0-r1 package from Gentoo/Linux). I have a long live record I have encoded in OGG (maybe it would have been easier to cut the WAV file and encode the parts, but still). The file was encoded with oggenc from the same package as vcut. I have therefore tried to use vcut to split the long OGG file in several smaller files. Actually, I have successfully separated several songs from the original file, but I have encountered a problem while reading those parts. Listening to the small ogg files is alright, but when I try to move forward or backward in the file (moving the position cursor), the player crashes. I first thought it was an XMMS (media-sound/xmms-1.2.7-r20) bug, but then I tried it again with Winamp, and the problem seemed to persist. Actually, Winamp didn't crash when I moved forward, it just skipped to the next song of the playlist, but there still seems to be a problem there. Now to make sure it was the original OGG file which was corrupted, I tried it again with a different file. The problem was still there. <p>Here is a simple recipe to reproduce the problem (I do not say bug for I'm not sure it is one) : $ # Let orig.ogg be the original ogg file $ vcut orig.ogg part1.ogg rest.ogg 1000000 $ vcut rest.ogg part2.ogg part3.ogg 1000000 $ xmms part?.ogg part1.ogg and part3.ogg are "searchable", but part2.ogg isn't. It seems like the file containing the beginning and the end don't have the problem, but the middle files do. <p>I have searched for similar bug reports but haven't found any, and I have not found threads discussing this in this ML archives either. My apologies if this is a dupe. -- Sebastien Cevey <seb@cine7.net> Cine7.Net - Milcis.Net - ProgramPlay.Org Jabber: theefer@albus.homelinux.net - ICQ: 48895760 " To condense fact from the vapor of nuance. " Neal Stephenson [ Snow Crash ] --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thursday 28 August 2003 11:09, Sebastien Cevey wrote:> Hello > > I have experienced some problems with vcut > (media-sound/vorbis-tools-1.0-r1 package from Gentoo/Linux). > > I have a long live record I have encoded in OGG (maybe it would have > been easier to cut the WAV file and encode the parts, but still). The > file was encoded with oggenc from the same package as vcut. > > I have therefore tried to use vcut to split the long OGG file in > several smaller files. >vcut is a proof-of-concept tool. It is known to have bugs (some of them serious) - if you want a real tool to do this, you'll have to find or write one (possibly - but not neccesarily - based on vcut). Patches are welcomed, but I have no intention of doing any more work myself with vcut. I'm considering dropping it from vorbis-tools for the next release, as it obviously causes some confusion. Arc's comments on vcut are partially correct (but gets some technical details wrong: granulepos is never negative, and vcut completely rewrites the stream rather than only the start), and his description of alternatives is a good idea to follow, if you want to. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.