Previous Page | Next Page

by mudlord88 at 2:04 PM EDT on September 9, 2015
@Tanookirby

I guess it shouldnt be too hard to do a XMPlay port, at any rate. I'd rather avoid Winamp like the plague.
by derselbst at 4:29 AM EDT on September 10, 2015
@kode54

no, just had a first look into the code. is there any special reason why you allocate the usf_state with that offset_to_structure?
by kode54 at 12:03 PM EDT on September 10, 2015
Yes, the SSE2 code in the LLE RSP requires aligned variables. I just align to 4K instead of some smaller figure.
by punk7890-2 at 10:01 PM EDT on May 10, 2016
I'm noticing errors in couple tracks of Hybrid Heaven:
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"D:\Music\Hybrid Heaven [ut] (1999-08-05)(KCE Osaka)(Konami)\sparse19.miniusf"
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"D:\Music\Hybrid Heaven [ut] (1999-08-05)(KCE Osaka)(Konami)\sparse64.miniusf"
by kode54 at 5:36 PM EDT on May 11, 2016
Maybe yet another rip that requires a re-rip and re-trim? Only using this library to perform coverage checking instead of Project64?
by punk7890-2 at 6:03 PM EDT on May 11, 2016
I don't know what you mean by: "Only using this library to perform coverage checking instead of Project64?" Not sure if that was aimed at me or not.

I noticed some popping in a few tracks from Extreme G also. Most notably Race 5. I don't know where the old lazyusf player went for foobar, but it never had these errors.
by kode54 at 9:55 PM EDT on May 11, 2016
Too bad I'm a big fan of improving things that aren't in need of improvement. I don't personally care that a handful of rips are broken by a switch to a faster and more accurate emulator, and that these games will likely need to be re-ripped using a whole new set of tools that haven't been invented yet.

The source code is available if anyone wants to try to fix it somehow. Pull releases welcome.
by punk7890-2 at 12:47 AM EDT on May 12, 2016
Unfortunately those tools probably will never surface. It's a shame that usf ripping isn't a thing anymore. Does anyone have a guide on how to rip a usf? I know no assembly but I can always bookmark it for later and try it (maybe) years down the road.

edited 2:05 AM EDT May 12, 2016
by hcs at 12:11 PM EDT on May 12, 2016
The problem is that there isn't really a good way of doing this crap that's documented, certainly the way I was going about it was bad. What guides there are refer to old, broken versions of Project 64 and Visual Studio 6, and ripping techniques that don't use much understanding. The result is the kind of broken rips kode54 is tired of hearing about.

What would be best is to take the idea and do new rips with modern, accurate emulators. Or better yet, come up with better ideas.

That said, here are the guides I know of:

USF FAQ has an overview
USF Case Study 1 (Killer Instinct Gold) Extreme G walkthrough (both from this old thread)

ugetab's USF Ripping Info


A lot of the links to the tools in those old old posts are dead, here I think are some recent ones:
IDA sigs
IDA save state loader module
Project64 v1.4 Source
PJ64 plugin source
tools

I don't have the exact version of "PJ64 USF" I mention, but this might work:
usfpj64-batchripperSOURCE2.zip

or this older stuff, I think I wrote this up for someone42 when he was doing Goldeneye:
list of files and guide for PJ64 USF, files are here

edited 12:18 PM EDT May 12, 2016

I've seen a few mentions of a document by someone42, that may be in reference to his extensive PSF ripping guide, though.

edited 12:29 PM EDT May 12, 2016

added some old freeshell.org files I'd forgotten about

edited 12:43 PM EDT May 12, 2016

I had forgotten about Nielk1's rip of "Battlezone: Rise of the Black Dogs" from 2014, this was probably the last USF rip done, so it is still possible.

edited 12:55 PM EDT May 12, 2016

unknownfile had two files mentioned
here and here, but they seem to be lost.

edited 1:16 PM EDT May 12, 2016

---

Final words:

I feel bad about how USF turned out. I thought that I could hack something together without understanding how N64 emulation really works, and I was almost right.

The specification relies on Project 64 save states intimately. It would have been better to keep things based on ROMs so that the "ground truth" for a working rip would just be whether it runs on an N64, and any accurate emulator would work. I even had the equipment to test on hardware, but for some reason I took another path.

kode54 and Josh W have done a lot of work to hack USF onto other emulators, but I think approaching it from scratch is the way forward. When I started 12 years ago, the only attempt at N64 music ripping was an unreleased Winamp plugin to play sequences, which just didn't work in general due to variation between games. I think someone with determination and an eye for quality can make another step forward.

edited 1:32 PM EDT May 12, 2016
by AnonRunzes at 4:21 PM EDT on May 12, 2016
Well then, let's develop a new format for playing N64 music. This time, it'll be like this:
64sf - for sequenced music
64str - for streamed music

But instead of using emulators and all that hax, why not hack some N64 ROM to use it as a driver? Or maybe something that can detect all the sounds/music from a N64 game? But first we'll need to carefully study the N64 hardware. THEN it's where you need to start from scratch. What do you think PSF originated from?

edited 5:06 PM EDT May 12, 2016

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

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