This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Xuggle 5.4 is available
#71
I tried the two files you attached and they played fine for me also (tried 5 times no errors)
>java -Djava.library.path=lib/windows-amd64-cp lib/xuggle-xuggler-noarch-5.4.jar com.xuggle.xuggler.demos.DecodeAndPlayAudio SND0(mega).AT3
>java -Djava.library.path=lib/windows-x86 lib/xuggle-xuggler-noarch-5.4.jar com.xuggle.xuggler.demos.DecodeAndPlayAudio SND0(mega).AT3
theme song plays. (same with SND0(3rd).AT3)

Serio >
did castlevania work on xuggle 3.4? I'm thinking that might be mono.
Reply
#72
it didn't work either now that i think about it. but neither did most of the other games i tried. every one of those had the same kind of header castlevania one does.
Quote: I'm thinking that might be mono.
nope, it's stereo. i used the mono tool thing to convert it to aa3 and loaded into sound forge, and it's regular stereo. to compare, i tried a mono at3 file from other game, and it was mono in sf too.

note, himdrenderer (one i have is 1.00 - beta 4) can convert the file into wav normally.
Reply
#73
legend80, I've tried playing the 2 AT3 files that you provided and not a single crash after playing them 10 times each. Have you tried my suggestion of resetting your CPU clock speed back to default and playing those files? I'm not saying that your system is not stable at 4.3GHz, but I was thinking perhaps the new ffmpeg in the new Xuggle is more timing-sensitive and can crash when playing certain files due to timing issues caused by overclocking. The new Xuggle includes new ffmpeg implementation that does things differently than the one in the old Xuggle. You should try testing it at default clockspeed just to rule out the possibility for certain. It's better to back up assumptions with actual facts and tests.
Reply
#74
i tried the older HiMDRenderer 0.50 and it also converts the file correctly. the one before that that i can find (0.31) doesn't even load at3 files yet, so i'm guessing 0.50's the first one that can.
Reply
#75
looking at the SND0-cv.AT3 file in ffmpeg i get this
[wav @ 0x207f9c0]max_analyze_duration reached
[wav @ 0x207f9c0]Estimating duration from bitrate, this may be inaccurate
Input #0, wav, from 'SND0-cv.AT3':
Duration: 00:00:32.34, bitrate: 64 kb/s
Stream #0.0: Audio: 0xfffe, 44100 Hz, stereo, 64 kb/s
Decoder (codec id 0) not found for input stream #0.0

0xfffe WAVE_FORMAT_EXTENSIBLE or ac3, seems to be some non common wav format or the headers are messed up

edit : nm it is a atrac3 file seems something is wrong with the header though so ffmpeg/xuggle isnt picking it up right
Reply
#76
yeah, the header has some additional bytes in it, and i guess the ffmpeg/xuggle devs never found a file like that, so it's not implemented on their end.

edit: i'm getting this from ffmpeg:
Code:
Input #0, wav, from 'SND0-cv.AT3':
  Duration: 00:00:32.24, bitrate: 64 kb/s
    Stream #0:0: Audio: atrac3p, 44100 Hz, stereo, 64 kb/s
SND0-cv.AT3: could not open codecs
1336306723.56 A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0
while the 2 that worked give me atrac3, this one's atrac3p. it's probably atrac3+ then, so i guess it should go through sonicstage instead of ffmpeg/xuggle.
Reply
#77
(05-06-2012, 02:44 AM)Itaru Wrote: legend80, I've tried playing the 2 AT3 files that you provided and not a single crash after playing them 10 times each. Have you tried my suggestion of resetting your CPU clock speed back to default and playing those files? I'm not saying that your system is not stable at 4.3GHz, but I was thinking perhaps the new ffmpeg in the new Xuggle is more timing-sensitive and can crash when playing certain files due to timing issues caused by overclocking. The new Xuggle includes new ffmpeg implementation that does things differently than the one in the old Xuggle. You should try testing it at default clockspeed just to rule out the possibility for certain. It's better to back up assumptions with actual facts and tests.

Tried stock speeds and even upgrading to Java7, no difference. Have no idea what's going on.

I'll just stick with the (slower) x86 for now and hope they update the x64 lib so it'll work better on my system.
Intel Core i7 6700k @ 4.5 ghz. / GeForce GTX 970 / 16 Gig Ram / Win 10
Reply
#78
the only thing else i can think of is try looking at libxuggle-5.dll using a program like dependency walker see if you are missing any files it needs or if it shows conflicts..etc
Reply
#79
(05-06-2012, 08:56 PM)hyakki Wrote: the only thing else i can think of is try looking at libxuggle-5.dll using a program like dependency walker see if you are missing any files it needs or if it shows conflicts..etc

All I get is this error, not sure how big of a deal it is.


Attached Files Thumbnail(s)
   
Intel Core i7 6700k @ 4.5 ghz. / GeForce GTX 970 / 16 Gig Ram / Win 10
Reply
#80
yeah ieframe is not an big issue, i don't see any other problems with the dll from that ss, so that means it must be something else causing the crash, like a invalid registry entry or something is corrupt, usually these types of problems its just better to backup and reinstall windows since they are troublesome to track down. You could try something like ccleaner to fix bad registry entry's but some claim it does more harm then good..
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)