I launch COMI in scummVM 2.6pre and my compressed data folder is not working anymore ...
It's normal ? Why ?
- Capture d’écran 2022-01-17 211236.png (7.74 KiB) Viewed 3778 times
COMI compressed data
Moderator: ScummVM Team
COMI compressed data
Hello,
I launch COMI in scummVM 2.6pre and my compressed data folder is not working anymore ...
It's normal ? Why ? Regards
I launch COMI in scummVM 2.6pre and my compressed data folder is not working anymore ...
It's normal ? Why ? Regards
Re: COMI compressed data
Curse of Monkey Island, Full Throttle and The Dig targets were recently updated to use a new sound/music engine called Digital IMuse.
The engine needs to access the original music/sound/speech data files (uncompressed) to be able to correctly (and like it was intended in the original) play back music/sound/speech.
Unfortunately there are so many different crunching routines and packed files floating around that it was not possible to support (all of those) packed audio data anymore.
@devs
Hope i got it right, feel free to correct me.
The engine needs to access the original music/sound/speech data files (uncompressed) to be able to correctly (and like it was intended in the original) play back music/sound/speech.
Unfortunately there are so many different crunching routines and packed files floating around that it was not possible to support (all of those) packed audio data anymore.
@devs
Hope i got it right, feel free to correct me.
Re: COMI compressed data
Thanks for this clarifications
Re: COMI compressed data
From what I understood one of the main reason why those compressed audio files are no longer supported is that they are lacking some data that was not used by the previous sound/music engine implemented in ScummVM. But the new and more accurate Digital iMuse engine mentioned by Raziel requires those.
It may be possible in the future to update the ScummVM Tools to compress the original audio files to a new compressed format that contains all the needed information. But that has not been done yet, so for now only the original uncompressed audio files are supported. And in any case the old compressed files cannot be supported.
It may be possible in the future to update the ScummVM Tools to compress the original audio files to a new compressed format that contains all the needed information. But that has not been done yet, so for now only the original uncompressed audio files are supported. And in any case the old compressed files cannot be supported.
Re: COMI compressed data
Correct! The games' original interpreters use the Digital iMUSE engine for audio; ScummVM has had a pretty good aproximation of that engine so far, but which lacked some important quirks which led to some audio bugs.Raziel wrote: ↑Tue Jan 18, 2022 7:19 am Curse of Monkey Island, Full Throttle and The Dig targets were recently updated to use a new sound/music engine called Digital IMuse.
The engine needs to access the original music/sound/speech data files (uncompressed) to be able to correctly (and like it was intended in the original) play back music/sound/speech.
Unfortunately there are so many different crunching routines and packed files floating around that it was not possible to support (all of those) packed audio data anymore.
@devs
Hope i got it right, feel free to correct me.
During the last year I restarted work for this engine from scratch and I've managed to pull off an accurate version, squashing all those bugs as a side effect.
While The Dig and COMI are structured in such a way that compressed audio would theoretically be feasible (but yes, it would require rewriting the correspondent ScummVM Tool from scratch), Full Throttle follows its VOC audio format so religiously that using any other format would require some serious rewrite of the new iteration of DiMUSE.
Re: COMI compressed data
Thanks for the clarification. So it seems compressed audio is not an option anymore, is it?
Can someone point to a tutorial to get the audio files from my original CDs working with the latest ScummVM?
Thanks!
Can someone point to a tutorial to get the audio files from my original CDs working with the latest ScummVM?
Thanks!
Re: COMI compressed data
See here: https://wiki.scummvm.org/index.php?titl ... key_Island
Open "Installation" and copy the files listed there.
The audio data is part of the resource files and will be handled by scummvm automatically once you start the game.
Open "Installation" and copy the files listed there.
The audio data is part of the resource files and will be handled by scummvm automatically once you start the game.
Re: COMI compressed data
@criezy
I noticed this new Digital iMuse engine was introduced in 2.6.0.
Previous version 2.5.1 still supported compressed audio files for these games. I am a bit concerned because there are some ScummVM ports for low-end systems (such as Wii) that suffer from storage limitations (In the particular case of the Wii, max SD size supported is 2 GB). This is also partly true for the Android port which has been halted in Google Play Store at version 2.5.0 so its still supporting compressed files, but whenever newer versions become available through the official Google channels users will face this lack of support for their compressed files, which I am sure most Android users use since the uncompressed files are 3x or 4x the size of the compressed ones.
I was curious about how feasible it would be to incorporate a future option to allow the user to use the old iMuse emulation engine instead of the new Digital iMuse (as a checkbox in Audio tab for example) thus providing support for the compressed files at expense of the known sound bugs, or having it unchecked using the new Digital iMuse engine by default. Would this require a huge effort in the implementation? Would it be worth it? I would like to hear your thoughts from you, the official developer.
I noticed this new Digital iMuse engine was introduced in 2.6.0.
Previous version 2.5.1 still supported compressed audio files for these games. I am a bit concerned because there are some ScummVM ports for low-end systems (such as Wii) that suffer from storage limitations (In the particular case of the Wii, max SD size supported is 2 GB). This is also partly true for the Android port which has been halted in Google Play Store at version 2.5.0 so its still supporting compressed files, but whenever newer versions become available through the official Google channels users will face this lack of support for their compressed files, which I am sure most Android users use since the uncompressed files are 3x or 4x the size of the compressed ones.
I was curious about how feasible it would be to incorporate a future option to allow the user to use the old iMuse emulation engine instead of the new Digital iMuse (as a checkbox in Audio tab for example) thus providing support for the compressed files at expense of the known sound bugs, or having it unchecked using the new Digital iMuse engine by default. Would this require a huge effort in the implementation? Would it be worth it? I would like to hear your thoughts from you, the official developer.
Re: COMI compressed data
I didn't work on the new digital iMuse engine (AndywinXp did most of the work).
But from a general perspective having two iMuse engines (the old that supports compressed files and the new) is not ideal as this makes the code more complex, with increased risks of bugs, and two engines to maintain. Also I don't know how similar or dissimilar the two engines are, and if it would be easy or not to have them coexist. A better solution, at least for The Dig and CoMI where that should be possible, would be to implement a new compress tool to create compressed files that are compatible with the new iMuse engine.
But from a general perspective having two iMuse engines (the old that supports compressed files and the new) is not ideal as this makes the code more complex, with increased risks of bugs, and two engines to maintain. Also I don't know how similar or dissimilar the two engines are, and if it would be easy or not to have them coexist. A better solution, at least for The Dig and CoMI where that should be possible, would be to implement a new compress tool to create compressed files that are compatible with the new iMuse engine.
Re: COMI compressed data
Thanks for your reply, criezy.
I agree with you that having both engines co-existing in the application would make the code more complex and harder to maintain.
As you well mentioned, for now there is no compressing solution with the new engine. I also agree that introducing a new compression method would make a much better solution than having 2 different engines that serve the same purpose in the code. However, I also read that there are no plans for that now, and building some new compression system supported by the new engine would be a huge effort (also taking into account it affects only 3 games). Besides, I read some people claiming that "storage is not an issue anymore", but of course they are maybe not taking the legacy and/or portable systems into account.
Anyway, I really appreciate your response and will be looking forward if somebody from the dev team decides to implement a solution for audio compression, whether it is backwards compatibility o a new compression method.
Have a great day ahead!
I agree with you that having both engines co-existing in the application would make the code more complex and harder to maintain.
As you well mentioned, for now there is no compressing solution with the new engine. I also agree that introducing a new compression method would make a much better solution than having 2 different engines that serve the same purpose in the code. However, I also read that there are no plans for that now, and building some new compression system supported by the new engine would be a huge effort (also taking into account it affects only 3 games). Besides, I read some people claiming that "storage is not an issue anymore", but of course they are maybe not taking the legacy and/or portable systems into account.
Anyway, I really appreciate your response and will be looking forward if somebody from the dev team decides to implement a solution for audio compression, whether it is backwards compatibility o a new compression method.
Have a great day ahead!