OpenCGSS / DereTore

Music and beatmap authoring toolkit for THE iDOLM@STER Cinderella Girls Starlight Stage (CGSS/DereSute/デレステ). / 偶像大师灰姑娘女孩星光舞台音乐&谱面制作工具箱
MIT License
187 stars 28 forks source link

HcaAudioStream doesn't seem to be seekable #65

Open segfault-bilibili opened 2 years ago

segfault-bilibili commented 2 years ago

I'm not majored in IT-related subjects. I'm not sure whether I misunderstand something for now, however I think something is (potentially) wrong.

The HCA (2.0, CBR?) decoding process seems to be "stateful" to me. Each block is not decoded "independently", let alone "disorderly". Every block relies on the state (decided/affected by its prior block) to be correctly decoded.

Currently EnsureSoundDataDecoded/EnsureSoundDataDecodedWithLoops takes position (in the name of waveDataOffset) as an argument - so what would happen if the stream got seeked? I haven't thought about this thoroughly, but I doubt whether the current code could correctly handle this.

segfault-bilibili commented 2 years ago

Ah, the fact that EnsureSoundDataDecoded etc taking position as an argument itself shouldn't be a problem - the problem is, in my humble opinion, it should iterate through every block from the beginning to the current position, rather than every block from the current position to the end (of loop).

segfault-bilibili commented 2 years ago

On the other hand, I think in a common streaming scenario, it should assume that the beginning part, rather than the following/ending part, is available.

segfault-bilibili commented 2 years ago

Hmm... Maybe making HcaAudioStream seekable isn't as challenging as I thought. However, anyway, because of the fact that every block depends on the state decided by its prior block to be correctly decoded, the beginning part still has to be (in the first place: available - and then) decoded in order, only after that could the decoder then hand out decoded WAV PCM data.

segfault-bilibili commented 2 years ago

Hmm... As for:

in a common streaming scenario, it should assume that the beginning part, rather than the following/ending part, is available

I think even if, like, the user drags the timeline/progress bar to skip some part in the beginning, (strictly saying) the decode still has no choice but to download & decode all prior blocks in spite of the fact that those block will probably never be used/played.

(However, according to my rough observation, the "effect" won't last for more than 1 block, so maybe fetching & decoding 2 prior blocks (rather than the whole part up to the beginning) is already enough)

segfault-bilibili commented 2 years ago

Ah, after skimming VGAudio's related code (related: https://github.com/Nyagamon/HCADecoder/issues/4 ), I think maybe (still not very sure) this "state/context" dependence problem shouldn't be as important as I originally thought.