I am reverse engineering the VAG format, which is a sound file format for the PSX (PlayStation 1). In the format, audio markers indicating audio looping points are encoded in the stream itself by a block attribute.Definition of possible attributes from a header found on the official SDK:/* block_attribute */#define ENC_VAG_1_SHOT      0#define ENC_VAG_1_SHOT_END  1#define ENC_VAG_LOOP_START  2#define ENC_VAG_LOOP_BODY   3#define ENC_VAG_LOOP_END    4Here is an excerpt of what flags/numbers are found when printing their content:For a 1 shot (no looping) sample:004000000000000000000000000000000000000000000000000000000000000000000001For a looping sample:026222222222222222222222222222222222222222222222222222222222222222222223As you can see, in both examples it is pretty easy to visually spot where are start/stop flags, whether for a 1 shot sample or a looping sample (confirmed by listening to the resulting WAV file).However, looking at their 'official' definition, the values by themselves are not what they should be. Basically, on a 1-shot sample there should be only 1-shot-related values, and for loops only loop-related values (again, confirmed by an encoder sample application found in the SDK).Could there be some trick/considerations involved when one should interpret these flags ?
Should these numbers be interpreted as flags or not, or something else?
file format;decompress
Something seems a bit weird here; i'd have expected the loop to look something like 233333334, not 62222223. And i'm missing a loop count, how would you encode a start that's played twice, mid-section that doesn't get repeated, and an end section that repeats forever, or until the end of the level?But that doesn't neccesarily mean some trick were intentionally involved. I'd assume Sony wrote the specs, published them to game creators, then implemented these specs in a certain way. The implementation probably doesn't check for violations of these specs, it just handles them in some way.Enter some software vendor who does a cross-platform game. They have their own music format, need to port it to the PSX, and write a converter. To test the converter, they convert some samples and listen to them, iterating until they sound right. After that, the converter might have gotten modified and enhanced several time, which introduced some bugs, but since the samples seem to work correctly, noone ever looks at the bytes anymore. Which means at some point they started violating the spec, but since the implementation doesn't choke at this, nobody knows about this.20 years later, you're the first one to ever notice.So yes, there could be some considerations involved how to interpret the flags, and maybe nobody ever knew what these considerations are. Best you could do is get some games from a different vendor, and look at how they encode music. This may give you an idea if you're just misinterpreting something or if your first sample actually don't match the spec. And if it does, and you want to handle this, you'll probably have to reverse the actual implementation in the PSP firmware to find out how to handle these edge cases.