I've got no clue what kind of hardware constraints are involved but it's probably best to make the limit variable and based on the system memory or user preference instead of just choosing an arbitrary time limit.

Yes, it really does come down to what KIND of files the person is going to play. A 15 minute decently compressed mp3 file isn't the worst, but when you get a 24-bit 96 kHz FLAC file... we start to get in tighter territory... ;)

Matt

Can't express how much I want to play through '... and then there was silence'

You're just talking about playback? Couldn't you just buffer it and read off the HDD as needed?

I figured it would be the analyzer/level designer that would eat up RAM with long playtimes. I don't do a lot of programing but that sounds a lot more complicated to me.

Yes, we do that, but the data that we analyze is MUCH larger than just storing frequency domain information (AND we are compressing it!). To get the intensity, beat detection and "important moments", we have to store a lot of game information. Streaming wise, there is no limit :)

EDIT: Ok, I see why you asked that. Sorry, it is NOT on playback... I misspoke in that message. Sorry!

Matt

OK, so it is the level designer/analyzer.

If the issue is with the resources needed for the level designer and it needs to analyze the whole track and not break it up piecemeal then the main things that influence memory usage should be length, bit depth and sample rate since even a 128kbps mp3 CD rip will still be decoded to 16/44.1 for normal playback and have lots of empty space above 14 khz or so before whatever lossless compression you use internally.

Of course the CD > mp3 > lossless recompress of the mp3 decode will have less data than the original CD > lossless but since you mentioned 24/96 FLAC files I'm guessing those are where you fan into problems with system resources.

Do you get any significant differences in the level (or really, any differences at all...) if you truncate bit depth to 16 and use a 22khz brick wall on high rez music before feeding it to the level designer? That would save lots of space.

It's not like anyone's going to actually have music with more than 96dB of dynamic range which 16 bit can do and 22khz is already past the limit of what most mics record even if most people could hear it so I wouldn't imagine that things which don't exist and can't be heard would have much effect on the level designer which seems to be based around human perception of the music data. I'm not the one that designed though...

Hey!

Actually, we normalize all of the frequency AND time-based data to a 64-bit floating-point value. From there, we use that data to generate a LOT of data that our game needs; there are all kinds of data structures, etc. We compress this data and THAT is what stays in memory. Also, it cannot be streamed as it needs to index values randomly (we have to determine "cool" moments, compare, etc.)

So the gating factor is really the total time... not the bit-depth, sample-rate or number of channels (well, ok, we don't support multi-channel just yet... it's on our feature list :) )...

Does that make sense?

Matt

OK. That makes it understandable.

I already got the random access thing because you need to analyze the song as a whole and temp files on the hard drive would be very slow. After that if you convert it all to the same data format then length would be the only thing that matters.

I'd assume that means there's no way to reduce memory footprint without redesigning the whole analyzer which would be way to much work even if it didn't compromise quality.

An option that set maximum length by available memory should still work though, right? Worst case scenario it looks a the track's length, tries to allocate the necessary memory, and then tells you "sorry, pick a different song" if you don't have enough.

Plan B would be an "offline" utility that generated the level cache overnight or something via great big temp files and lots and lots of drive flogging but I don't know if would be too hard to implement.

Ha ha, or... just allocate more virtual memory from the system ;)... We might free up some memory from other systems, so this would be where we put it.

Matt

Well, some of us have tons of ram and resources, some people don't. But maybe you could scan the available ram/total ram and warn people with low resources that it will take an age to play a long song. Looking forward to playing some long Opeth stuff sometime...

Ha ha, ya know what? Windows treats everyone "the same" as it uses Virtual Memory and let's our program pretend like there is 2 gigs available for all use (EVEN if you don't physically have that!).

Unfortunately, it also takes quite a bit of RAM for DirectX... so unfortunately, we have to treat everyone the same and make sure it works for all machines, etc.

Mind you, if you do only have 512 megs or RAM or something, pretty much every modern game that displays quite a bit is going to have some interesting side-effects :).

Matt

Well, I know that, but using virtual memory that caches on hdd will slow the game into oblivion...

Hm, maybe then make analyzer interruptable so user can cancel it if things seem to be going sour. But again, it will be a bad user experience and the game will obviously take the blame. I guess the current solution is better in that regard.

Nontheless ... it would mean a ton to some of us to be able to play longer stuff. Even if that is in the first expansion.

well technincally you could, since some audio books are broken down into small clips, rather then 1 chapter per file (like I own melting stones by tamora pierce, each CD has like 50-80 clips, but it's only like 3 chapters, and like 1-2 hours per CD (and there are 8 CD's)

there are also programs you can use to split or join audio files, if you were that dedicated,

Yes, but that are 2 songs then, not one.

pee break, phone call break, break to force you to be responsible and stop procrastinating. essentially the save and quit ability ;)
I do see where you are coming from, if your audio book isn't small audio files less then 10 minutes, myself I'd rather have the extra files, for pause and breaks, then one song, being forced to keep the game going for progress. Also you loose all that extra koodos you would gain from completing more songs (well deserved), since I doubt the limit would increase much just 'cause the song is longer.
But if you have the filter on you can select the audio book, and with minimal breaks follow the story in game. I actually wouldn't pay this game with sound on if I wanted to listen to an audio book, as I think the noise would block out the voices. BUT that's my opinion, doesn't make it the correct one.