On Mon, 26 Jul 2004 21:06, O Si Yo wrote:> I don't know if this has been suggested before but.. > > What about adding support for a bookmark or > hyperlinked index? > > The idea is that a large compilation such as a long > speech or an album would be maintained as a single > file, but on playback, the player would show numerous > 'tracks' which are really just bookmarks relating to > starting position of the specific part or topic.Players can, in principle, do this already by treating each logical stream within a physical stream as a 'track'. In practice, it's best to treat each logical stream that has it's own set of vorbiscomments as a track, as stringing together sets of logical streams is used as a means of lossless editing of vorbis files by the likes of Audacity. Check out the xmms vorbis plugin in CVS here: http://savannah.nongnu.org/cgi-bin/viewcvs/vgplay/vgplay/ It's a bit out of date compared to current XMMS, but it should serve as a proof of concept for other player developers. John
<200407262114.35691.jwm@eslnz.co.nz> Message-ID: <200407261514.42528.haxe@pansensack.de> On Monday 26 July 2004 11:14, John Morton wrote:> Players can, in principle, do this already by treating each logical > stream within a physical stream as a 'track'.To me, that doesn't sound like a good solution. Imagine I have a seekable Ogg/Vorbis file that has a size of several gigabytes and contains, say, 20 "tracks". Of course, I want the 20 track marks to be listed without having the player seek through all the gigabytes of the file (which would be the case with just treating concatenated logical streams as tracks, or am I getting it wrong here?). With Vorbis content, it seems a rare case to have a several gigabyte seekable Ogg file, but with Theora content this sounds perfectly sensible. And the track marks in question would be like the chapters of a DVD. Is there possibly already a solution for such listed-in-advance trackmarks in Ogg/Theora, which could then be used for Ogg/Vorbis as well? Hauke Hachmann
<200407262114.35691.jwm@eslnz.co.nz> <200407261514.42528.haxe@pansensack.de> Message-ID: <200407270253.58473.jwm@eslnz.co.nz> On Tue, 27 Jul 2004 01:14, Haxe wrote:> On Monday 26 July 2004 11:14, John Morton wrote: > > Players can, in principle, do this already by treating each logical > > stream within a physical stream as a 'track'. > > To me, that doesn't sound like a good solution. > > Imagine I have a seekable Ogg/Vorbis file that has a size of several > gigabytes and contains, say, 20 "tracks". Of course, I want the 20 > track marks to be listed without having the player seek through all the > gigabytes of the file (which would be the case with just treating > concatenated logical streams as tracks, or am I getting it wrong > here?).Some observations: - vorbisfile already scans the entire physical stream, if it's seekable, to find logical streams, so what I'm doing is just exploiting this fact. If you want to avoid this, you'll probably need to roll your own open function out of libvorbis. - How is one big file and a pregenerated index better than several small files? After all, the "pregenerated index" is exactly what the file system is doing, and existing players all know how to ask the file system where each file begins right now, where as you'd have to train them to use some separate index system.> With Vorbis content, it seems a rare case to have a several gigabyte > seekable Ogg file, but with Theora content this sounds perfectly > sensible. And the track marks in question would be like the chapters of > a DVD. Is there possibly already a solution for such listed-in-advance > trackmarks in Ogg/Theora, which could then be used for Ogg/Vorbis as > well?DVD's tend to break down films into separate vob files for titles, at least. Given the relative easy of joining multiple chapters together for, say, bittorrent network transport, and spliting them for faster access, you'll probably find the leaving that kind of course grained indexing to the filesystem is much less bother. John
<200407261514.42528.haxe@pansensack.de> <200407270253.58473.jwm@eslnz.co.nz> Message-ID: <200407261847.42274.haxe@pansensack.de> On Monday 26 July 2004 16:53, John Morton wrote:> - How is one big file and a pregenerated index better than several > small files? After all, the "pregenerated index" is exactly what the > file system is doing, and existing players all know how to ask the > file system where each file begins right now, where as you'd have to > train them to use some separate index system.Of course. I love filesystems, and in most cases a filesystem serves much better than an index within the file. But when you want to share something that consists of several tracks, it is often desirable to have it all in one file to ensure it's integrity. Of course you can put all track files in one zip file (I have sometimes seen this for albums), but then you need a player that understands to directly play the contents of a zip file if you don't want to manually unpack it all. So for this purpose, it would be better to have a track index in a big ogg file. Players that understand this index can show the tracks correctly, and players that don't understand the index can at least play the entire file as one track. In this sense, introducing an indexing technique would be backwards compatible and thus much better than just putting all tracks in one zip file. greetz, Hauke Hachmann
<200407261514.42528.haxe@pansensack.de> <200407270253.58473.jwm@eslnz.co.nz> <200407261847.42274.haxe@pansensack.de> Message-ID: <20040726175745.GF971@xiph.org> On Mon, Jul 26, 2004 at 06:47:42PM +0200, Haxe wrote:> > So for this purpose, it would be better to have a track index in a big > ogg file. Players that understand this index can show the tracks > correctly, and players that don't understand the index can at least > play the entire file as one track. In this sense, introducing an > indexing technique would be backwards compatible and thus much better > than just putting all tracks in one zip file. >The command for this has been in UNIX for a very, very long time. You don't even need libogg/libvorbis to use it: # cat track1.ogg track2.ogg track3.ogg >album.ogg Every player currently out there will see it as one big file, but it'd be quite easy for a player to be written that could scan the file, know that they are different tracks, and display them as such. You will need, however, an Ogg-enabled tool for splitting these apart into tracks later. Fairly simple to write with py-ogg2. See examples/reserializer.py for an example of how to work with "chained" Ogg files.
<200407261847.42274.haxe@pansensack.de> Message-ID: <4105533F.8000509@ellisfoundation.com> Haxe wrote:>On Monday 26 July 2004 16:53, John Morton wrote: > > >> - How is one big file and a pregenerated index better than several >>small files? After all, the "pregenerated index" is exactly what the >>file system is doing, and existing players all know how to ask the >>file system where each file begins right now, where as you'd have to >>train them to use some separate index system. >> >> > >Of course. I love filesystems, and in most cases a filesystem serves >much better than an index within the file. > >But when you want to share something that consists of several tracks, it >is often desirable to have it all in one file to ensure it's integrity. >Of course you can put all track files in one zip file (I have sometimes >seen this for albums), but then you need a player that understands to >directly play the contents of a zip file if you don't want to manually >unpack it all. > >So for this purpose, it would be better to have a track index in a big >ogg file. Players that understand this index can show the tracks >correctly, and players that don't understand the index can at least >play the entire file as one track. In this sense, introducing an >indexing technique would be backwards compatible and thus much better >than just putting all tracks in one zip file. >I think this feature of having one file recognized as multiple tracks/chapters would be very nice for Vorbis, but absolutely necessary for Theora. If you tried to watch the Full Length movie "Honey" (I think that's what it was called) in Theora when the bitstream freeze was announced, I'd think many would agree. For short clips, it's not necessary. However, for long movies/videos it is very important and most players don't mix multiple video files together as one smooth presentation well at all. Also think of seeking on streamed content, wouldn't it just be great to hit next chapter instead of trying to find where the next part starts? Paul Ellis
<200407261847.42274.haxe@pansensack.de> Message-ID: <001401c4734b$dd9a60c0$857c94ac@themet> Can Ogg files be augmented to allow album art to be displayed or attached to the actual file itself?
<20040726175745.GF971@xiph.org> Message-ID: <001501c4734b$e5c34e60$857c94ac@themet> How does one "peel" an ogg vorbis file.... say for instance... a 192kbps file down to a 96kbps? Do you have to reenlarge the original ogg to a wav and then transcode to the lower bit rate?
<200407261847.42274.haxe@pansensack.de> <20040726175745.GF971@xiph.org> Message-ID: <200407262258.53799.haxe@pansensack.de> Oh sorry Arc, this mail should have gone to the vorbis list, so once again:... On Monday 26 July 2004 19:57, you wrote:> The command for this has been in UNIX for a very, very long time. > You don't even need libogg/libvorbis to use it: > > # cat track1.ogg track2.ogg track3.ogg >album.oggYes, I know that, and it is a very good feature. But I was explicitly talking about a trackmark index that doesn't require to scan through the whole file. The bigger your file is, the more useful such a trackmark feature can get. But also, the bigger your file is, the longer it takes to seek through all the data for logical stream boundaries. Thus, it can be very useful to have an index of logical trackmarks at the beginning of a seekable file as an optional feature. Hauke Hachmann
<200407261847.42274.haxe@pansensack.de> <001401c4734b$dd9a60c0$857c94ac@themet> Message-ID: <80cc888e040726180935a750c2@mail.gmail.com> On Mon, 26 Jul 2004 14:54:50 -0500, Ken <ken@oggcafe.com> wrote:> Can Ogg files be augmented to allow album art to be displayed or attached to > the actual file itself?Yes. You can mux in any file you want. You might have to compile the tools, though. http://www.vorbis.com/faq.psp#container
<20040726175745.GF971@xiph.org> <001501c4734b$e5c34e60$857c94ac@themet> Message-ID: <80cc888e0407261816569fd2c1@mail.gmail.com> On Mon, 26 Jul 2004 14:58:45 -0500, Ken <ken@oggcafe.com> wrote:> How does one "peel" an ogg vorbis file.... say for instance... a 192kbps > file down to a 96kbps? > Do you have to reenlarge the original ogg to a wav and then transcode to the > lower bit rate?You do it with a peeler. A peeler works on a compressed Vorbis file, not on a decompressed file. It's difficult to find a good peeler, though. Not many peelers exist, let alone good ones.
<001501c4734b$e5c34e60$857c94ac@themet> <80cc888e0407261816569fd2c1@mail.gmail.com> Message-ID: <001c01c473a2$b5635a60$9440fea9@petty> Are there any peelers that you would suggest to try, or have links to. Thanks ----- Original Message ----- From: Kyungjoon Lee <kjoonlee@gmail.com> To: Ken <ken@oggcafe.com> Cc: <vorbis@xiph.org> Sent: Monday, July 26, 2004 6:16 PM Subject: Re: [Vorbis] Peeling> On Mon, 26 Jul 2004 14:58:45 -0500, Ken <ken@oggcafe.com> wrote: > > How does one "peel" an ogg vorbis file.... say for instance... a 192kbps > > file down to a 96kbps? > > Do you have to reenlarge the original ogg to a wav and then transcode tothe> > lower bit rate? > > You do it with a peeler. A peeler works on a compressed Vorbis file, > not on a decompressed file. > > It's difficult to find a good peeler, though. Not many peelers exist, > let alone good ones. > >
On 26/07/2004, at 7:06 PM, O Si Yo wrote:> I don't know if this has been suggested before but.. > > What about adding support for a bookmark or > hyperlinked index? > > The idea is that a large compilation such as a long > speech or an album would be maintained as a single > file, but on playback, the player would show numerous > 'tracks' which are really just bookmarks relating to > starting position of the specific part or topic. > > i.e. Audio books could be indexed by chapters or > sections or in the case of music albums, each track > title would be listed with the ability to select any > of interest. > > a potential expansion would be for lesson type files, > which could be tracked by some sore of progress ap, to > save the last lesson listened to and perhaps jump to a > section where review is indicated. > > Mainly the idea is to keep all the sections together > as one file, but to allow for random access to > sections / topics etc.The ideas that you're speaking of are very similar to what we're working on with the Annodex project: http://www.annodex.net/ In particular, the "hyperlinked index" that you speak of can be done with CMML, an XML-like markup language which contains annotations, metadata, and hyperlinking information: http://www.annodex.net/TR/draft-pfeiffer-cmml-01.html (or follow the "Specifications" link from the main Annodex page) One CMML document can reference an arbitrary number of video/audio/other streams, and by using the command-line tools on the website, it's possible to merge them all into a single "Annodex" file, which is what you're after. This all works today; however, I see two problems with what you want to do: 1. The tools are a bit primitive at the moment: no fancy GUI point'n'click tools exist here to annotate your video with metadata. They work fine for developer use, though, and the developer libraries are mature enough to use now. 2. Although the Annodex encapsulation format is based on Ogg, Annodex files are not quite compatible with Ogg files, unfortunately (although this is something that we may be changing in the future, to achieve 100% compatibility with standard Ogg files). So, you'll need a player which explicitly supports Annodex files for this to work. At this time of writing, the only player which supports both Annodex files and CMML is VideoLAN. The support is pretty bare: you can follow hyperlinks specified in CMML markup to other files, but full web browser-like functionality is still a fair way off. The CVS version of xine supports Annodex files as of a few weeks ago, but has no support for CMML yet. I'm working on that now. If you're really interested, email me in private or on one of the Annodex mailing lists if you'd like more info. -- % Andre Pang : trust.in.love.to.save
--- Haxe <haxe@pansensack.de> wrote:> Oh sorry Arc, this mail should have gone to the > vorbis list, > so once again:... > > On Monday 26 July 2004 19:57, you wrote: > > The command for this has been in UNIX for a very, > very long time. > > You don''t even need libogg/libvorbis to use it: > > > > # cat track1.ogg track2.ogg track3.ogg >album.ogg > > Yes, I know that, and it is a very good feature. But > I was explicitly > talking about a trackmark index that doesn''t require > to scan through > the whole file. > > The bigger your file is, the more useful such a > trackmark feature can > get. But also, the bigger your file is, the longer > it takes to seek > through all the data for logical stream boundaries. > Thus, it can be > very useful to have an index of logical trackmarks > at the beginning of > a seekable file as an optional feature. > > Hauke Hachmannsome of the uses I foresee would be lessons, groups of speeches on theme, and audio books etc. With high compression for voice only files, it is possible to have 50-100 hours or more of good quality audio on a CD. For these types of uses, ability to have direct access to particular sections is most needed since it would be hard to do 100 hours in 1 session or keep track of where one left off. Also, a special dedicated front end ap might be useful for lessons and the like, keeping track of progress, perhaps having some sort of testing for comprehension of parts covered, suggesting review of particular sections when needed. This would incorporate indexed ogg files as a resource. Learning a language could be such a use. For language lessons, I could imagine voice recognition being used, to compare the students attempts at repeating words being learned. If it compares reasonably well to the teachers pronunciation, then the student progresses to the next word or phrase. If not, then the student is requested to try again for a few times until their pronunciation matches the teachers. If the student just can''t seem to get it at the time, that fact is stored and then the program would take the student to another lesson, to return later to review areas of past difficulty. also, to enhance this function and such uses.. years back I suggested adding support for imbedding text fields for lyrics and transcripts. For songs, having the lyrics imbedded in the ogg file would make it easily searchable. If you recall a few words of the song, you can quickly find the song itself. Same with the transcript of a talk. If you remember the words you wish to locate, somewhere in a 3 hours speech, it again would be easily searchable and with the transcribed words linked to their place in the audio file, one could scan the transcript, then click on a word to jump to replay the audio from that point. I just discovered 2 days ago that mp3 specs have been expanded to include lyrics3 tags that can in fact be time stamped, to facilitate a karaoke style video output. If this can be used for large transcripts as well, it would be a boon for presentations that would allow the blind to listen while allowing the deaf to read the text being scrolled in time on a video display. I just re-subscribed to this list so am not at all upto date on current project status and direction. Does ogg have anything like the mp3 lyrics3 tags implemented or planned? __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
I don''t know if this has been suggested before but.. What about adding support for a bookmark or hyperlinked index? The idea is that a large compilation such as a long speech or an album would be maintained as a single file, but on playback, the player would show numerous ''tracks'' which are really just bookmarks relating to starting position of the specific part or topic. i.e. Audio books could be indexed by chapters or sections or in the case of music albums, each track title would be listed with the ability to select any of interest. a potential expansion would be for lesson type files, which could be tracked by some sore of progress ap, to save the last lesson listened to and perhaps jump to a section where review is indicated. Mainly the idea is to keep all the sections together as one file, but to allow for random access to sections / topics etc. desirable? doable? __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail