Previous Page | Next Page
- by furrybob at 10:40 PM EST on December 21, 2017
- @bnnm
It's the holiday season, so I'm unsure about my schedule and when I'll start/finish the port, but if you want to get a head start, you could add ATRAC9 decoding by using Sony's decoder. Then when I do the port, all you'll have to do is swap the decoders since I'm using the same interface.
Here's an old library version along with an example of how to use it.
- by bnnm at 6:49 AM EST on December 28, 2017
- @furrybob - Ok, did my part (wink wink).
One thing I worry though is that keeping lib/function names 1:1 may "atrac"t (har har) Sony's wrath. I mean, it replaces a private tool that Sony would want to control with an iron fist and only licensees should have knowledge of. Maybe some renaming would be safer?
- by Knurek at 6:47 PM EST on December 28, 2017
- @bnnm: Should I start prepping JoshW archive for it? As with the PSP sets, I'd need to remove the .POS files and regenerate playlists, then reupload most of sets...
- by bnnm at 7:16 PM EST on December 28, 2017
- Well, maybe furrybob will be busy and won't be able to port it for a while or such. But since he publicly posted his C# decoder (much appreciated) it's a matter of time until done. I can tell you loops and decoding should be equivalent to Sony's stuff, so it's up to you. Personally, those .pos/playlists don't bother me though.
I can upload Freedom Wars/Gravity Rush/Soul Sacrifice Delta original .SXD meanwhile if you want.
- by furrybob at 2:05 PM EST on December 29, 2017
- @bnnm
Maybe it would be a better decision to rename some stuff. I've already put together an open-source, binary-compatible replacement for Nintendo's dsptool.dll, but Nintendo cares less about that kind of stuff than Sony does.
Great, reading ATRAC9 from various container formats appears to be in place. Maybe I missed it, or maybe it's still private, but do you have the calls to the ATRAC9 library done yet?
- by bnnm at 2:39 PM EST on December 29, 2017
- @furrybob - here is the actual decoder if you want to check it (renamed obvious calls), works fine for all files I tested.
Didn't upload yet as I felt a bit anxious about using Sony's lib calls, but if that's what you'll really use I could go ahead. Just feeling the less reasons for them to make a "cease & desist" thing the better, but maybe they won't care as this stuff is super-niche anyway.
Might do minor restructuring to support "EATrax" (EA's ATRAC9 in .sps) and some simplifications too (ex. sceAt9GetCodecInfo can be easily replicated, GetHandle/DecInit/DecDecode/ReleaseHandle are the only calls really needed if you want to skip the rest).
- by furrybob at 3:54 PM EST on December 30, 2017
- Right, there are a few options I see:
1. Use the same API as Sony's library
Pros: Can be used as a drop-in dll replacement for the official library. Source and binary compatibility with programs using the official library, statically or dynamically linked.
Cons: Sony's legal department has an itchy trigger finger.
2. Use the same API, but rename the calls and structures.
Pros: Might help avoid legal issues.
Cons: No source or binary compatibility with official library, but source compatibility would only require changing some names.
3. Ignore the official library's API and implement whatever seems reasonable.
Pros: Freedom to change the API.
Cons: Would require changes to a program using Sony's library. Using the open-source library with closed-source programs would require a shim or something.
As a side note, major architecture differences aside, I've found porting (or at least an initial port) the library's individual functions from C# to C is mostly a matter of copying and pasting.
Sure you have to tweak some stuff to work with pointers, but there's hardly any rewriting going on.
The decoder included with VGAudio (link) took the 3rd route, and the API looks something like what's listed below.
The calls are simpler and less abstract than Sony's decoder, and the information structure provides more detail (noise?) about the stream.
class Atrac9Decoder
{
Atrac9Config Config;
Atrac9Decoder();
void Initialize(byte[] configData);
void Decode(byte[] atrac9Data, short[][] pcmOut);
}
class Atrac9Config
{
Atrac9Config(byte[] configData);
byte[] ConfigData;
int SampleRateIndex;
int ChannelConfigIndex;
int FrameBytes;
int SuperframeIndex;
ChannelConfig ChannelConfig;
int ChannelCount;
int SampleRate;
bool HighSampleRate;
int FramesPerSuperframe;
int FrameSamplesPower;
int FrameSamples;
int SuperframeBytes;
int SuperframeSamples;
}
- by bnnm at 6:13 PM EST on December 30, 2017
- 2 is a good compromise, but I'm not sure if people really need compatibility (if you are a licensee you have the original lib, if you aren't you'll use whatever), the lib is apparently meant to be a testing or dev tool anyway.
3 would simplify the API I guess, good as vgmstream only needs to do superframes and minimal config_data info.
Well, either way works as I can change it anytime, whatever is easier or cleaner for you.
- by furrybob at 2:15 AM EST on January 3, 2018
- Initial port posted. (Very initial. I'm basically just posting the first working code.)
I renamed the function names just before pushing. The function names and signatures are subject to change, but if they do, the changes should be minor.
- by bnnm at 11:20 AM EST on January 3, 2018
- Seems to work fine with all my tests files. I don't have any actual >2ch though. IIRC Vita can't do band extension, and all my PS4 samples didn't, not sure if later games do.
Lib calls may have collisions/shadowing without some prefix though, I think Windows used GetHandle somewhere.
Previous Page | Next Page
Go to Page 0 1 2 3 4
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source