Previous Page | Next Page

by hcs at 9:14 PM EDT on April 22, 2009
Maybe this will help:
I see that you're sending the WM_WA_MPEG_EOF message as soon as your decoder is done. In 64th Note what I do is:

while (mod.outMod->IsPlaying()) Sleep(50);
mod.outMod->Close();
mod.SAVSADeInit();
PostMessage(mod.hMainWindow,WM_WA_MPEG_EOF,0,0);

along with some other fiddling with emulation state.
Out.h says: "(i.e. closing while IsPlaying() returns 1 would truncate the song"
by SmartOne at 10:34 PM EDT on April 22, 2009
The equalizer stuff as an option would be interesting, but I prefer not to use it.
by Mouser X at 11:10 PM EDT on April 22, 2009
For me, the biggest limitations that in_mgme has is the song ending too early (hopefully what HCS said will be helpful there), lack of silence detection (that would help a lot on GBS files...), VGZ not working (is that just me?), and skipping through subsongs (which has already been addressed. It is a limitation, but it's one I can live with). Being able to read the M3U tags would be icing on the cake.

If all these issues are handled, then in_mgme would replace NotSoFatSo, NEZplug, in_vgm, and maybe even SNESAmp (I'm very satisfied with RSN extensions. However, since I use in_zip anyway, it wouldn't be a big deal to rename all the RSNs to RAR, thereby feeding them from in_zip through to in_mgme).

On the note of subsong skipping and in_zip.... When in_zip reads an archive, it adds entries to the playlist. Ex: Drag+drop an archive onto Winamp, Winamp loads the archive (be it ZIP, RAR, 7zip, etc.), in_zip reads the archive, and creates playlist entries that it understands (and thus when Winamp loads those playlist entries, they're forwarded directly to in_zip, which then extracts the file referenced, and forwards it to the correct plugin). Perhaps in_mgme could do something similar (it'd be optional). When a file with subsongs is loaded, add playlist entries for each subsong. These entries would specify exactly which subsong to play.

Here's what I'm seeing: Once M3U tags are implemented (you said there's already a means to read them in place, right?), in_mgme could (if the option is turned on to do so) add individual playlist entries for each subsong, using the M3U tags as the added entries. This way, the user loads one file (the NSF, GBS, etc.), and when Winamp gets to it, that file is then split up into multiple playlist entries (and the original file is removed from the playlist). I assume that since in_zip is able to add custom playlist entries to the playlist (immediatly after the archive in the playlist), that in_mgme could do the same, using the M3U tag specifications.

So far, that's the best I've got. Excluding your current method to handle subsongs (which, knowing your arguments now, makes good sense), I really can't think of anything else.

Did all that make sense? I'd be happy to provide more in-depth examples/explanations if they're needed, but I'm not sure if anything needs more clarification right now. Mouser X over and out.
by mudlord at 11:59 PM EDT on April 22, 2009
@Mouser X: Can you please supply some test files for me to have a look at?
by SmartOne at 12:01 AM EDT on April 23, 2009
The GBS support is not nearly as accurate as NEZplug++. One test case: Pokemon R/B/Y, a few subsongs in, Noise, or at least percussion desyncs and takes on a mind of its own.

Pretty sure NSF accuracy is inferior as well, especially the VRC6 emulation, etc. NEZplug++ is rock solid for 8-bit formats, as far as I can tell.

I haven't been able to play any VGZ. Looking into an archive plugin. The 7-Zip XMPlay plugin doesn't seem to work.

Oh yeah. VGZ = gzip. Still need a plugin...
For VGZ, keep an eye on in_vgm2.
http://www.smspower.org/maxim/forumstuff/in_vgm_latest/
(Check for the most recent.)
Hopefully Maxim will continue to work on it.
http://www.smspower.org/forums/viewtopic.php?t=11593

edited 12:30 AM EDT April 23, 2009
by Mouser X at 12:32 AM EDT on April 23, 2009
Test files of what? I'll provide links to the files I've recently downloaded and played in Winamp, if that's what you're looking for.

Legend of Zelda, The - Oracle of Ages [Zelda no Densetsu - Fushigi na Ki no Mi - Daichi no Shou] (GBC)(2001)(Flagship)(Nintendo).zip (GBS test)
Legend of Zelda, The - Link's Awakening DX [Zelda no Densetsu - Yume o Miru Shima DX] (GBC)(1998)(Nintendo EAD)(Nintendo R&D2)(Nintendo).zip (GBS test)
Tetris (1989)(-)(Nintendo).zip (M3U tags testing - didn't work unless I had NEZplug enabled)

Legend of Zelda, The (1986)(Nintendo EAD)(Nintendo).zip (NSF testing)
Crystalis (NSFe test)
MegaMan 3 (NSFe test)
Zelda (NSFe test)
Zelda 2 (NSFe testing)

Mahoujin GuruGuru (1995)(TamTam)(Enix).rsn (renamed to *.rar, played through in_zip)
Mahoujin GuruGuru 2 (1996)(TamTam)(Enix).rsn (renamed to *.rar, played through in_zip)

The Itchy & Scratchy Game (beta) (VGZ testing)
Star Trek - Deep Space Nine: Crossroads of Time (VGZ testing. I took the first song from this set, extracted it with 7zip (which resulted in a file with no extension), added *.vgm to the end, and it played)

To the best of my recollection, these are the sets I either played with in_mgme, or was going to play with in_mgme. Some of them (the SPC sets for certain) I played from within their archive, using in_zip. Hopefully that's what you were looking for? Mouser X over.

edited 12:47 AM EDT April 23, 2009
by mudlord at 12:44 AM EDT on April 23, 2009
@Mouser: All I asked was for test files for the GBS problem you described. Thanks for all the other files, they will help greatly.

@SmartOne: That might be something blargg might need to look into....

edited 12:47 AM EDT April 23, 2009
by Mouser X at 12:57 AM EDT on April 23, 2009
Just so I'm clear on that, I assume you're refering to the buffering/song ending too soon problem? That's a problem I have with all files that have (and adhere to) track lengths. Specifically, I noticed it the most with the SPCs. So far, I haven't encountered serious problems with GBS/NSF files, other than that they play infinitely (even when 3 minutes is reached, they keep playing). Though, I would assume that, were they to stop when they were supposed to, that they too would suffer from the truncation issue.

Hopefully that's what you meant? Mouser X over.
by mudlord at 1:01 AM EDT on April 23, 2009
Yes, I was referring to the silence detection issue. Which really, should have not been a problem since I do use the functions in the API to detect silence (unless its related to the problem HCS elaborated on).

I am well aware of the issue with SPCs, everyone seems to get that. Hopefully, hcs's code works fine.

anyway, here is a permalink to the files since I have no webspace:

http://mudlord.fileave.com/
by Mouser X at 1:58 AM EDT on April 23, 2009
Oh crap!!! I just remembered that the file I was using (regarding silence detection) was on my PC, and therefore it was being played with NEZplug++. The file isn't online (that I can find) anymore. It's a GBS rip by ugetab of all the sound effects from Link's Awakening. I requested it, because I wanted the "unlearned ocarina" song that's played when Link hasn't learned any songs yet. So there's a good chance my mentioning of silence detection was ill-founded. :( Sorry about that.

As for in_mgme, I assume the version from that link (the EXE) is the most recent one? I'm still having the same problem. I looked through in_mgme.txt, and I saw that you tested it for around 8000, so I tried that. Yes, it works with your buffer at that setting. With it at 10000 though, it doesn't (it cuts off 2-3 seconds too soon). This implies to me that you're doing some form of counting in the output. In my experience, a plugin that suffers from this problem cuts off at the point that the buffer is set to load the next file. This is not the case with in_mgme, as the cutoff is delayed to (I assume) exactly the amount you tested it at. This leads me to assume that, somewhere in your code, it's doing a count that only lasts up to 8000.

I also noticed your comment about in_gsf having the same problem. I downloaded in_gsf just now to try it out (since I didn't recall having this problem) along with Yoshi's Universal Gravitation (it takes the least amount of CPU, I hope). I listened to a few files, and they didn't end early (even though my buffer settings were all set to max). However, I'm fairly certain they ignored the buffer settings (the CPU didn't behave as I would expect it too, if the next file was being loaded/rendered). Of course I don't expect you to care about that. I just wanted to see for myself if the issue was duplicated there.

Also something of interest. When possible, I play songs through in_zip. Just to be certain in_zip wasn't getting in the way, I extracted the GSFs and SPCs, and tried them from a directory instead.

What is the default length for silence detection? With 64th Note, HCS had to put in a fix so that it would continue playing the file, even though it had rendered to the silence detection limit. To quote the 64th Note history text file:

09/09/05 - 64th Note v1.0 beta 4 released
* silence detection now won't end a track until it's actually played to the point where
the silence starts, which should fix things for users with large buffers (before the
track would end as soon as the specified amount of silence was *rendered*)

What I'm wondering is, if your silence detection is high enough (I realize 8-9 seconds is very high for silence detection. I have encountered some games that need more than that though), if it would suffer from the same problem. That is, the song cuts off when the silence is rendered, rather than when the silence is actually reached by the user/speakers.

I'm wracking my brains trying to come up with ways I can help out more to narrow down the problem. Right now though, I can't do any more than I already have. :( Mouser X over.

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source