Which means at some point they started violating the spec, but since the implementation doesn't choke at this, nobody knows about this.Ģ0 years later, you're the first one to ever notice.
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. To test the converter, they convert some samples and listen to them, iterating until they sound right. They have their own music format, need to port it to the PSX, and write a converter.
The implementation probably doesn't check for violations of these specs, it just handles them in some way.Įnter some software vendor who does a cross-platform game. I'd assume Sony wrote the specs, published them to game creators, then implemented these specs in a certain way. 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?īut that doesn't neccesarily mean some trick were intentionally involved. Something seems a bit weird here i'd have expected the loop to look something like 233333334, not 62222223.
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).Ĭould there be some trick/considerations involved when one should interpret these flags ?
However, looking at their 'official' definition, the values by themselves are not what they should be. In the format, audio markers indicating audio looping points are encoded in the stream itself by a block attribute.ĭefinition of possible attributes from a header found on the official SDK: /* block_attribute */ I am reverse engineering the VAG format, which is a sound file format for the PSX (PlayStation 1).