Closed GoogleCodeExporter closed 8 years ago
I guess i will leave at least one open with hope that if people never read the
documentation coming with emulators, they will see it and give up flooding the
issue reports with the same known stuff again and again :-)
Original comment by ekeeke31@gmail.com
on 11 Jul 2012 at 9:00
Issue 246 has been merged into this issue.
Original comment by ekeeke31@gmail.com
on 11 Jul 2012 at 9:38
Issue 246 has been merged into this issue.
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 6:00
About the subject:
i would suggest converting original audio files to the wii samplerate, i.e from
44100 to 48000 Hz as it would save a lot of the wii CPU processing time and
can easily be done externally by computer applications. This apply to wav and
ogg files.
Another solution could be to have the emulator decode (when using ogg files)
and resample audio files automatically when loading a new cd game, into
temporary raw audio files that would be used dufor real-time emulation. Again,
this could greatly speedup emulation of cd tracks since it would save up
decoding and resampling processing time, with the downside of requiring extra
size (max.600 mb) on sd/usb and extra initial loading time for writing the
temporary files.
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 6:03
will it be possible to use a "raw" iso (bin/cue) or will the audiotracks have
to be converted to at least wav?
Original comment by gora.pat...@gmail.com
on 12 Jul 2012 at 6:54
It should be supported but might be slower than separated iso + audio files.
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 7:00
[deleted comment]
[deleted comment]
This is in response to comment #4:
Is there a way you can offer both as a user selectable option in the emulator
settings? The reason I ask is because with method #2, some of us may not have
600 MB extra space on our SD cards and it can create issues if the emulator
chooses to do this method automatically. Maybe have option #1 as default and
the more careful users can select method #2 by choice.
Original comment by tegskywa...@gmail.com
on 12 Jul 2012 at 7:24
It's only theoretical right now, i don't even know if it is realistic. I
obviously won't force such behavior if it is too much annoying to use.
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 7:26
I don't know if this is even worth considering, but if you're going to support
.ISO + WAV, it would be fairly easy to support .ISO + ADPCM to help with the
space problem. That wouldn't be too much larger than high quality MP3's, and
still be quick to load and decode. I believe the GC/Wii DSP can decode ADPCM in
hardware anyway, but since there are Genesis romhacks that actually use ADPCM
for digital audio, it's light enough that you could decode it in software with
minimal impact.
Original comment by sappharad
on 19 Jul 2012 at 1:09
This is an interesting idea indeed although i think that ADPCM decoding still
need to be done in software by the DSP and require nintendo's proprietary
library to be loaded. I am not sure if libogc DSP module (included with ASND or
AESND libraries) supports this, i need to check but don't think it is the case.
And even if it was, it would require to completely change the way whole audio
is processed by the emulator since those libs need to handle audio DMA in their
own way, so it might end up being more complicated than it seemed in the first
place.
Regarding mp3, i have identified Helix MP3 decoder from Real Networks which is
also used in Picodrive and which license seems to be compatible with our
license. Need to check further if it is worth implementing when ogg decoding is
already there with libtremor...
Original comment by ekeeke31@gmail.com
on 19 Jul 2012 at 3:59
[deleted comment]
[deleted comment]
[deleted comment]
You can use cue/iso/wav. The audio tracks in a cue file can be named as
separate files & whatever audio format you prefer, data can be an iso.
Original comment by johnkenn...@gmail.com
on 21 Jul 2012 at 2:39
I'm not the world's greatest DSP programmer but wouldn't upsampling from 44100
to 48khz in realtime be reasonably light? My understanding is you don't need a
high quality algorithm, or filtering, when going up in sample rate because it
doesn't really create aliasing problems. If you took it and mixed it in with
the Genesis output, you could just enable the lowpass filter by default and set
it to a lenient value (98, 99%?) to filter the whole output. If it's too much
for the Wii to handle or causes slowdowns, how about an option to automatically
enable lower quality FM when playing Mega CD? Lots of Mega CD games don't use
FM for much other than sound effects anyway. Forgive me if I'm making big
assumptions here, I'm not familiar with exactly how the emulator is put
together internally.
Dustin
Original comment by sonocolo...@gmail.com
on 21 Jul 2012 at 10:00
The automatically enable lower quality for Mega/Sega CD Games sounds perfect to
me.
Original comment by Dragzill...@yahoo.com
on 22 Jul 2012 at 1:09
You can always disable HQ FM if you want, but it's bad design to do it
automatically under some situation.
Linear interpolation from 44.1 to 48 khz should *in theory* be fine for CD
audio tracks and not too much CPU time consuming but in practice, proper
resampling might be needeed to avoid clicks or noise: i think that when the
original signal has lot of harmonics close (or above ?) to the max frequency
(i.e 22.05 khz), interpolation does not give very good result. Well, we will
see, i know gens/picodrive are doing basic interpolation (not even linear) to
resample 32khz PCM to 44.1hz output.
As for filtering, it must be specific and applied during the resampling,
low-pass filter applied on the output probably won't be efficient enough.
Anyway, my idea was that for external compressed audio files (obviously for bin
image the raw audio will need to be resampled), it could be better to have them
already resampled by an external program because 1) it would be better quality
resampling 2) it will still save CPU time for other tasks, like decompressing
for example. Seems quite logical to me and honestly i don't really care if
people complains about having to resample their iso "collection" if this makes
emulation better and faster.. In most cases, you will already have to convert
mp3 to ogg so why not resampling them as well ?
Original comment by ekeeke31@gmail.com
on 22 Jul 2012 at 8:39
If that's the direction you think is best, how about the pre-processing
resampling idea, but doing it on the Wii side? For example, the first time you
launch a bin/cue, inform the user that it has to be preprocessed once before
running. Have genplus extract the tracks from the bin, resample them and encode
them to ogg. Extract the data track to iso (or even better, if not too hard to
implement, CSO, like picodrive). Once complete give the option of deleting the
bin/cue.
If this solution got used, it would be best if the "converted" game could be
added to, say, an xml list that includes the iso and the audio tracks it uses,
so that so it could be easily selected and have a "clean" entry in the file
selector. You could even store the TOC in there for games like Snatcher.
Personally, it wouldn't really bother me to have to do the conversion on my PC,
but it would be nice to have the functionality built right into genplus.
Original comment by sonocolo...@gmail.com
on 22 Jul 2012 at 1:30
Yes, that's what I suggested on comment #4 although I'm not a big fan of
converting accurate bin+cue dump to something less accurate. If post-processing
is done, then better uncompress everything and use RAW or WAV audio file
converted to 48khz so the emulator only has to read files and write data back
to audio buffers, without any additional processing. Compressed ISO will not be
supported as it will only add more processing to decompress the iso data in
real time, it's not really a matter of how "hard" it would be to implement than
how "useful" it is beside leaving more rooms on storage device.
Again, if it was not clear enough, my goal is not to make it easier to store as
many games as possible on USB stick or small SD cards, it's to make it so that
emulation remains accurate while still being running full-speed and without any
frame-skipping. If that's only possible by using fully uncompressed CD images
with audio files resampled to 48khz RAW data and leaded to 1GB by game file, I
would still do it. Hopefully, the Wii is powerful enough to decompress OGG file
or interpolate CD audio to 48khz while handling the existing hardware emulation
process.
Original comment by ekeeke31@gmail.com
on 22 Jul 2012 at 2:20
Off topic, I have come across some BIN/CUE images that were actually holding
WAVE files inside the BIN file. Is that something normal and allowed by the
CUE/BIN format ? The CUE file mentions the start of raw audio track inside the
.bin file but it points to a "RIFF WAVE" header before actual raw data. Or
maybe that's a badly reconstructed CD image that was done using external WAV
files ?
FILE "Earthworm Jim - Special Edition (Sega CD) (U).bin" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 00 01:31:14
INDEX 01 01:33:14
...
006daff0:00 00 00 00 00 00 00 00 00 00 00 00 52 49 46 46 ............RIFF
006db000:dc c1 0b 00 57 41 56 45 66 6d 74 20 10 00 00 00 ÜÁ..WAVEfmt ....
006db010:01 00 02 00 44 ac 00 00 10 b1 02 00 04 00 10 00 ....D¬...±......
006db020:64 61 74 61 8c c1 0b 00 ef ff 1c 00 e9 ff 14 00
dataŒÁ..ïÿ..éÿ..
Original comment by ekeeke31@gmail.com
on 22 Jul 2012 at 2:43
I've actually seen this before. Provided the bin/cue isn't badly dumped, or a
bad CD image, it may be actually a mastering error. Most mixed mode CDs that
have this problem have a little click before the audio starts playing, because
of the header. I can't recall any Mega CD games that I know of with the problem
but I've seen it on other discs.
In response to your comment 21, I'm in total agreement. I'm sure most people
using genplus are running off of USB hard drives or large SD cards anyway. I
would much rather be able to load & run unmodified bin/cue files myself. As far
as audio tracks being stored as ogg files, that would probably eat up more CPU
time than just resampling the raw audio in realtime, but I wasn't really giving
it much thought. I peeked at the source--is the FIR resampler too "heavy" to
apply to the CD audio?
By the way eke-eke thanks for the thoughtful replies, the fantastic emulator
(it is the best emulator of any system on the wii), the Sega CD support and
everything.
Original comment by sonocolo...@gmail.com
on 22 Jul 2012 at 3:11
Here is my two cents about the audio situation and available SegaCD roms.
CoolRom (www.coolrom.com) - ROMs are in ISO format with MP3s
Emuparadise (www.emuparadise.me) - ROMs are in BIN format with CUE
Say for example you try Final Fight CD or Sonic CD from Emuparadise with the
BIN/CUE combination. I have looked at the CUE files that come with the BIN and
there is no mention of a WAV extension. Say we were to rip that BIN file into
an ISO with WAV or OGG files, will a new CUE file have to be created to
specifically look for WAV/OGG ?
Original comment by tegskywa...@gmail.com
on 22 Jul 2012 at 7:15
Attachments:
[deleted comment]
ISO+wav or any type of separated audio files normally does not require cue file because the TOC can be guessed from the different files length/format. You can still use a cue file but the image format is obviously different from a plain .bin dump and each file must be explicitely mentionned. See online documentation if you have more question about cue files.
I am planning to support bin+cue anyway so you really should not bother about
having to convert anything, i was only discussing the conversion of existing
audio files to a suitable rate and format...
Original comment by ekeeke31@gmail.com
on 22 Jul 2012 at 8:00
It's a real shame no one reads the user manual - you've got the best manual
I've seen in a long time for an emulator and I often find myself looking at it
just cause of all the nice detail and care put into it, keep up the good work :D
As for ADPCM route, I'd also advise against it if you want to get it done some
time this lifetime ;) (you'd need to write your own copy of the proprietary
ADPCM decoder or learn to use the Nintendo one and have it provided in some BIN
format by the users.. too much fussing around..)
I would recommend using ASND/AESND (AESND utilizes more special DSP
instructions to get higher performance on GameCube than ASND) and having the
users provide the files in MP3 format or something else lossy and low
bandwidth. Although I'm not sure how much CPU you have to spare on the GameCube
to software decode the MP3. Another thing to consider is that on GameCube the
SDGecko is going to do polled I/O reads so you want to minimize bandwidth to
minimize CPU blocking from I/O.
When we did CDDA support in WiiSX, it considerably brought down the framerate
using the raw data from the ISO, but we never got around to trying anything
else or performing optimizations on the ugly PC driver we ported.
Just my thoughts - again, keep up the great work - I was amazed when I ran
Sonic CD on my GameCube, amazing work :D
Original comment by emuki...@gmail.com
on 25 Jul 2012 at 4:19
Thanks for the input ;-)
Yes, i expect some performance drop with audio track support but hope not so
much (it's actually the same as continuously streaming data from usb/sd like
fmv games are doing already, with additional resampling or decompression
eventually). I already thought about using DSP through AESND (mainly for the
resampling) but, unless i missed something, it finally seemed too much
complicated since i need to keep control on audio DMA lengths (to prevent any
audio/video desync) and it would probably means redesigning completely the way
the emulator is outputing samples.
It's nice that Mega CD games are running fine on Game Cube, i still have my
original modded one from good old tehskeen time but it seems like my sd-gekko
adapter got lost or trashed so i couldn't test it. I wasn't much optimistic
about the framerate however.
Original comment by ekeeke31@gmail.com
on 25 Jul 2012 at 8:09
Yes, that's the problem with AESND, it really does require a re-write of
anything that wasn't designed to use it in the first place.
Good luck with it, I'm personally looking forward to seeing it (or listening to
it rather):)
Original comment by emuki...@gmail.com
on 25 Jul 2012 at 11:18
Linear interpolation can be done in a few lines of code, and I think it sounds
fine. It shouldn't create much overhead at all, and you won't need to
incorporate an external library for it.
You can find an example of it at the very bottom of the attached file. (This is
the code I used for the ADX playback in the Gamecube Disc Browser)
Original comment by sappharad
on 29 Jul 2012 at 7:19
Attachments:
Thank you for the code but i am planning to use blip_buffer linear
interpolation instead (it's very similar actually, just add a little bit of
high-pass filtering). This way, better resampling using band-limited synthesis
from blib buffer library could also later be used (i plan to add options for
"high-quality" CD, PCM and even PSG this way).
Original comment by ekeeke31@gmail.com
on 30 Jul 2012 at 8:34
Speaking of formats for CD audio emulation, perhaps it would help checking out
how the SCUMMVM team handled the CD tracks?
They currently support WAV, OGG and even FLAC without slowing down the games
(although I'm pretty sure they aren't as CPU intensive since it's not
emulation).
Original comment by superballena
on 31 Jul 2012 at 9:06
Also, MESS and MAME have also implemented FLAC support lately. Here's a post
Haze made a few months ago about it, for the record:
http://mamedev.emulab.it/haze/2012/01/18/taking-the-flac/
Original comment by superballena
on 1 Aug 2012 at 9:58
Yes, FLAC is a nice lossless library although my goal isn't to support all
possible audio formats because emdedding external libraries has signicant
costs. The advantage of ogg is that libtremor is already there and being used.
As for taking inspiration from other emu implementations, this isn't really useful or applicable because every apps are designed differently and have different requirements. Also, the use of decompressing libraries is pretty much standard, i doubt that scummvm or mess do something special beside using the existing documented API . From the discussion you linked, it's more about how to correctly and efficiently compress CD image existing sets to replace CHD format.
Anyway, don't worry, i already have a pretty clear idea about existing audio
tracks formats and how i it's gonna be done, just missing time to really get my
hands on it, especially with vacations finally coming on their ways. It's also
very likely that compressed audio files support won't come immediately and that
next release will first attempt to deal correctly with Cue+Bin and Iso+Wav
images.
Original comment by ekeeke31@gmail.com
on 2 Aug 2012 at 3:27
Issue 273 has been merged into this issue.
Original comment by ekeeke31@gmail.com
on 31 Aug 2012 at 1:35
So is there no way to get music to play currently? I tried Final Fight (two
different versions). One the game wouldn't play and the other the game would
play but the music wouldn't.
Original comment by jlenoco...@gmail.com
on 31 Aug 2012 at 7:12
You got it.
Original comment by superballena
on 2 Sep 2012 at 6:28
Yes this Final Fight CD is an issue everyone is aware of. Many games play no
music at all except for some in game music like in Sonic CD when you go to a
hidden area & music plays. Ekeeke is working on stuff, just be patient.
Original comment by punkydud...@gmail.com
on 4 Sep 2012 at 5:51
Original comment by ekeeke31@gmail.com
on 30 Sep 2012 at 5:42
Added in r715
Original comment by ekeeke31@gmail.com
on 13 Oct 2012 at 5:05
Original comment by ekeeke31@gmail.com
on 13 Oct 2012 at 5:06
Original issue reported on code.google.com by
zgl...@gmail.com
on 11 Jul 2012 at 1:30