I am with Orangy Tang on this. You should use URLs. You don’t even need to use different separators with urls as it is the same on all platforms. My entire resource system for the game uses URLs. It works really well, i can point to files in jars, or even extend the URL handlers for a custom game “pak” file design if i want. Also i have used the JOrbis with it, i don’t recall having any problems.
I don’t think this is right. In what context can you something on Windows with ‘/’?
Some headway with figuring out the specs on Ogg: the frame counts that I want are stored in the “Granule Position” portion of the header for every Page. An Ogg file comprises a series of Pages. So, I’m thinking one can maybe stream the file, parse the headers and “throw away” the vorbis compression data itself. A lot depends on how clear my head feels when I get to this later today!
I think, philosophically, one wants to use URL or InputStream as much as possible with a game, as that is the mechanism given for loading resources from a Jar. Creating a dependancy where one needs to write files on a client seems to me to be asking for avoidable trouble. The problem here is that the JOrbis code that provides VorbisFile info (such as frame length) relies on a RandomAccessFile implementation.
Yes, OggVorbis files can play back perfectly well without finding out the frame counts. My goal is a API that allows one to “overlap” file playback where the loop time can be specified via a plus or minus value added to the existing frame count. In other words, 0 = looping as usually implemented, -1000 would be start the second iteration one second before the end of the file, 1000 would be to leave a one second gap. It’s possible to make the API simply be one that uses an absolute, positive value, but I think the relative positioning will be a lot easier to use.
Another possible direction: I may instead make a pre-compilation utility that extracts frame counts and stores a text file of file names and frame lengths, then pack the resulting text file with the ogg files as a resource amd load it into a HashMap at game loading time. It adds a step when compiling, but it is a small step. The game time savings would only occur during loading, but if one is building soundscapes with 1000’s of SFX files, I suppose that could make it worth something.
Yeah, made the pre-compilation thang.
The utility opens each audio file and puts its file name and frame length into a text file. Does them all, in one swoop. Then, the program opens this file with a Scanner (which can run off of resource’s InputStream) and loads a HashMap that can be consulted when I make my various multiple-Cue-playing constructs and want to know cue timings.
It seems like a bit of a cop out to go so far with possibly adding to JOrbis, but I think this may be a more practical design, long range. I kind of like having some of the functionality of this system out of reach of decompilers, as well as decreasing the startup load.
Anyway, it works! And an exported Jar is running some looping .ogg cues like a charm. So, maybe time to detour and go back an build this stuff into Hexara. We should be able to drop its 3 minute load time down to about 15-20 seconds.
Thanks, all!