Previous Page | Next Page

by MarkGrass at 1:38 PM EST on February 1, 2008
There's been alot of in_cube releases' already this year...*head splodes*

Keep up the great work!

edited 1:39 PM EST February 1, 2008
by starerik at 4:43 PM EST on February 1, 2008
Is there a chance that you can decode the Xbox 360 audio format XMA?
by hcs at 5:47 PM EST on February 1, 2008
No. As far as I know, no one knows how it works yet and there are no software decoders. Probably not too different from WMA, but I don't know enough about that to try messing with it.
I'd certainly love to support it, Blue Dragon has some really neat tracks, and Lost Odyssey almost certainly uses it as well but I'm not downloading 4 dual-layer DVDs worth of material to find that I can't do anything with it.
How to compile without MFC by MegaByte at 6:37 PM EST on February 1, 2008
This is for MarkGrass.

In dsp.rc, replace

#include "afxres.h"

with

#include <winresrc.h>
#define IDC_STATIC (-1)
by MarkGrass at 8:55 PM EST on February 2, 2008
Thanks for the tip, MegaByte, but I still cannot compile in_cube. I now get this error:

1>wamain.obj : error LNK2019: unresolved external symbol __imp__IsDlgButtonChecked@8 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__GetDlgItemTextA@16 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__EndDialog@8 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__CheckDlgButton@12 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__SetDlgItemTextA@12 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__SendMessageA@16 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__GetDlgItem@8 referenced in function _configDlgProc@16
1>wamain.obj : error LNK2019: unresolved external symbol __imp__DialogBoxParamA@20 referenced in function _config
1>wamain.obj : error LNK2019: unresolved external symbol __imp__MessageBoxA@16 referenced in function _about
1>wamain.obj : error LNK2019: unresolved external symbol __imp__PostMessageA@16 referenced in function _DecodeThread@4
by MegaByte at 9:08 PM EST on February 3, 2008
Then you'll need to add libraries to the Linker configuration. Not sure why they're not already included in your build, but check Google for which lib files contain those symbols and you should be able to complete your build.



I figured out a fix for the WinAMP 5.52 crash. It seems some initialization happens in a different order in this version, and some expected info isn't there when in_cube files are already in the playlist upon launch. The fix is to remove the check for !*filename in getfileinfo in wamain.c. I compiled a fixed copy, which can be found here. Unfortunately, I built with Visual Studio 2008, which requires the installation of this as well.

edited 10:32 PM EST February 3, 2008
by hcs at 12:02 AM EST on February 4, 2008
So it gets a null filename?
Rather, a null pointer?

edited 12:03 AM EST February 4, 2008
by MegaByte at 12:16 AM EST on February 4, 2008
Yeah. I don't know much about WinAMP plugins, but the crash is only hit when that pointer is NULL, which only seems to happen (in my very brief testing) when in_cube files are already loaded into the playlist before starting WinAMP.
by hcs at 3:21 PM EST on February 6, 2008
When that pointer is NULL the !filename test should fail and it should never get to !*filename...

Well, anyway here is in_cube 0.35 with your fix (I have no way of testing it, I can't get a crash) and some extra fun stuff from FastElbja.
by MegaByte at 12:24 AM EST on February 7, 2008
Err right; I misspoke. The problem seems to be that filename does exist, but the cubefile structure is not properly initialized. The crash actually occurs in the getlength function. I believe the sample_rate comes back as zero, resulting in a divide by zero error. Removing the !*filename check simply forces InitCUBEFILE to execute in that particular case, which solves the problem. There's almost certainly a better fix for the crash, but that was the simplest patch code-wise. in_cube 0.35 doesn't crash, so the fix still holds, but I guess it would be instructive to figure out why the cubefile initialization has changed (or maybe there's a race condition somewhere, which would explain different results on different machines?)

Here's an optimized build for those that are interested. It seems to load files faster, but I haven't analyzed playback performance. VC9 runtime required. For reference, I added the following compile options: /Ox /Ob2 /Oi /Ot /Oy /GT /GL /GF

edited 12:43 AM EST February 7, 2008

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10

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