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_BODY   3
#define ENC_VAG_LOOP_END    4

Here is an excerpt of what flags/numbers are found when printing their content:

For a 1 shot (no looping) sample: 004000000000000000000000000000000000000000000000000000000000000000000001

For a looping sample: 026222222222222222222222222222222222222222222222222222222222222222222223

As 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 ?

1 Answer 1


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.

  • Thanks, I guess you're right ! Just tried with 3 games and they all exhibit the same behavior. Too sum it up one should watch for 4 and 1 for one shots, and 6 and 3 for loops, period. Once again the KISS approach, using merely FC and sticking to these hints was right. But my curiosity caught me and I ended in a trap... (I think this specific, pre-SPU-stage format has been replaced by the more contemporary ATRAC, in the PSP)
    – aybe
    Commented Oct 23, 2015 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.