Loop point in an OGG

[princec]

I’m using JOrbis to decode Ogg Vorbis streams and send little chunks to OpenAL.
What I’d like to know is - has anyone got any tips about setting a “loop” point, where the stream resets itself back to a particular point in time and continues reading from there until stopped? I don’t think I can just arbitrarily choose any old byte in the file because it’ll be in the middle of a “frame” of Ogg data, so I need to know how, given a specific timecode, I can set the stream read point back to where this time occurs. If you see what I mean.

Cas

[Riven]

At the risk of being captain obvious to the rescue…

You have the decoded data that you send to OpenAL. While decoding/streaming, you can store it somewhere (either RAM or disk) and jump to a ‘N byte aligned random offset’ and pass the next samples to OpenAL again.

[paulscode]

@Riven

You have the decoded data that you send to OpenAL. While decoding/streaming, you can store it somewhere (either RAM or disk) and jump to a ‘N byte aligned random offset’ and pass the next samples to OpenAL again.

That would eliminate the resource-saving benefit that you get from streaming an OGG (i.e. taking advantage of the small size of OGGs and only hanging onto to a small chunk of the much larger decoded data at any one time).
I actually need something like this as well for a method I’m adding to my sound library, so I’ll post the solution if I happen to discover it before you do, princec.

[Riven]

Well doh. But often you just want your download to be as small as possible. As soon as you’re installed… who cares.

[paulscode]

@Riven

As soon as you’re installed… who cares.

True for an application, but optimization is still a big concern for applets, where there is a maximum amount of memory you can use. There are of course more than one solution to every problem, so which one is best ultimately depends on the project and whatever constraints you are working under.

[delt0r]

The ogg container format defines what would work with seeking. Generally a ogg packet/page boundary should work, but vorbis uses an overlapping transform. So that may be a good thing–in that it will smooth out any clicks from an abrupt level change. OTOH it may cause the next 2? blocks to get pretty distorted.

I think the software decoding lib should have some seeking hooks. That would be the correct way to do it if possible.

[Riven]

@paulscode

True for an application, but optimization is still a big concern for applets, where there is a maximum amount of memory you can use. There are of course more than one solution to every problem, so which one is best ultimately depends on the project and whatever constraints you are working under.

LWJGL/OpenAL uses a signed applet. They can easily hack in support for the allocation of direct bytebuffers (or simply use mapped files for ByteBuffers up to 2GB) and dump your sound data inthere.

[paulscode]

@Riven

They can easily hack in support for the allocation of direct bytebuffers (or simply use mapped files for ByteBuffers up to 2GB) and dump your sound data inthere.

True for signed applets, but in the case of unsigned ones using Java Sound instead of LWJGL, that wouldn’t be an option. This may work in princec’s case depending on what his project is (it may not even be an applet). But in my case, if at all possible I don’t want to require the user to sign his/her applet when using my library. One of its appeals is the possibility of a simple 3D sound system in pure Java. Coupled with a pure Java software-rendering 3D engine, and you can create game applets that don’t require applet signing or for the user to click a security warning.

[Nate]

You can keep track of the number of bytes decoded. I’m pretty sure if you decode X bytes, then you can sometime later give the OGG decoder bytes starting at offset X and be sure to be on whatever boundary OGG expects.