OniGalore

OBD:SNDD: Difference between revisions

OBD Discussion

OBD:SNDD (view source)

Revision as of 18:27, 31 May 2020

5,203 bytes removed ,  31 May 2020
wrapping up the Mac SNDD knowledge; thanks to Ed for the main menu recording
(→‎PCM export: PC demo detection)
(wrapping up the Mac SNDD knowledge; thanks to Ed for the main menu recording)
Line 1: Line 1:
{{OBD_File_Header | type=SNDD | prev=QTNA | next=StNA | name=Sound Data | family=Generic | align=center}}
{{OBD_File_Header | type=SNDD | prev=QTNA | next=StNA | name=Sound Data | family=Generic | align=center}}


 
:''For metadata instances used to group sounds together, randomize them, adjust their volume or frequency, etc, see [[OSBD]] and its subtypes: [[OSAm]], [[OSIm]] and [[OSGr]].''
There are 2 different formats used by the SNDD files. Both versions use a form of [[wp:ADPCM|ADPCM]] compression (Adaptive Differential Pulse-Code Modulation), where 16-bit sound samples are encoded as 4-bit nibbles (resulting roughly in a 4:1 compression ratio as compared to uncompressed 16-bit [[wp:PCM|PCM]]).
SNDD instances is where Oni stores sound data. Sounds can be either mono or stereo waveforms (with sampling frequencies of either 22.05 kHz or 44.1 kHz), and they are typically compressed to save on storage space. Both the PC and Mac versions use a form of [[wp:ADPCM|ADPCM]] compression (Adaptive Differential Pulse-Code Modulation), where 16-bit sound samples are encoded as 4-bit "nibbles" (resulting roughly in a 4:1 compression ratio as compared to uncompressed 16-bit [[wp:PCM|PCM]]).
*On PC (both retail and demo), sounds are encoded using Microsoft's ADPCM algorithm described [https://wiki.multimedia.cx/index.php/Microsoft_ADPCM HERE]. [[wp:FFmpeg|FFmpeg]] lists this codec as '''adpcm_ms'''.  
*On PC (both retail and demo), sounds are encoded using Microsoft's ADPCM algorithm described [https://wiki.multimedia.cx/index.php/Microsoft_ADPCM HERE]. [[wp:FFmpeg|FFmpeg]] lists this codec as '''adpcm_ms'''.  
*On Mac, sounds are encoded using the IMA4 algorithm described [https://wiki.multimedia.cx/index.php/Apple_QuickTime_IMA_ADPCM HERE]. [[wp:FFmpeg|FFmpeg]] lists this codec as '''adpcm_ima_qt'''.
*On Mac, sounds are encoded using the IMA4 algorithm described [https://wiki.multimedia.cx/index.php/Apple_QuickTime_IMA_ADPCM HERE]. [[wp:FFmpeg|FFmpeg]] lists this codec as '''adpcm_ima_qt'''.
The PC demo and Mac SNDDs come short of PC retail SNDDs in the following respects:  
;Key shortcomings of the PC demo and Mac SNDDs as compared to PC retail SNDDs:
*PC demo and Mac SNDDs only support one sample rate (22.05 kHz). PC retail supports arbitrary sample rate, allowing 46 electric spark sounds to use CD-quality 44.1 kHz (for crisper high frequencies).
*PC demo and Mac SNDDs have a "short" .dat part that specifies only the frame count (animation length in game ticks) and number of channels (mono or stereo). The waveform data is always assumed to be sampled at 22.05 kHz, and compressed into 4-bit ADPCM (either IMA4 or MS ADPCM).
The Mac SNDDs come short of PC SNDDs (both retail and demo) in the following respects:  
*PC retail supports arbitrary sample rate, which allows for crisper high frequencies: specifically, 44.1 kHz (CD quality) is used for the 46 electric spark sounds '''ap_hit_shld''' and '''zap##'''. Possibly PC retail supports uncompressed PCM waveforms as well.
*At 22.05 kHz, Mac SNDDs (IMA4) are about 5% larger than PC equivalents (MS ADPCM), because of a much smaller block size in the .raw part (the smaller .dat part of Mac SNDDs doesn't help).
; Key shortcomings of Mac SNDDs as compared to PC SNDDs (both retail and demo):  
*Mac SNDDs have encoding/editing artifacts at the ends of looping segments (music and ambient tracks). Only PC SNDDs (retail or demo) can be pieced together seamlessly. See [[OBD:SNDD#Looping_issues|BELOW]] for details.
*At 22.05 kHz, the storage size of Mac SNDDs (IMA4) is about 5% larger than for PC equivalents (MS ADPCM), because of a much smaller block size in the .raw part (the smaller .dat part of Mac SNDDs doesn't help).
*Mac SNDDs have encoding/editing artifacts at the ends of looping segments (music and ambient tracks). PC SNDDs (retail or demo) have no such artifacts and allow nearly seamless playback. See [[OBD:SNDD#Looping_issues|BELOW]] for details.
==Oni storage==
==Oni storage==
===PC retail===
===PC retail===
Line 33: Line 34:
|}
|}


The .raw data contains the actual audio sample blocks without any other headers (other than block headers).
The .raw data contains the actual audio sample blocks without any other headers (other than ADPCM block headers).


====.raw part (MS ADPCM)====
====.raw part (MS ADPCM)====
Line 63: Line 64:
|}
|}


The .raw data contains the actual audio sample blocks without any other headers (other than block headers).
The .raw data contains the actual audio sample blocks without any other headers (other than ADPCM block headers).
====.raw part (MS ADPCM, PC demo)====
====.raw part (MS ADPCM, PC demo)====
For PC demo the .raw SNDD data is actually the same as for PC retail, but with the same short .dat header as on Mac. The ADPCM block size is 512 bytes for mono, and 1024 for stereo. The sample rate is 22.05 kHz.
For PC demo the .raw SNDD data is actually the same as for PC retail, but with the same short .dat header as on Mac. The ADPCM block size is 512 bytes for mono, and 1024 for stereo. The sample rate is 22.05 kHz.
Line 71: Line 72:
:The first two bytes of each block are used to set the initial predictor (upper 9 bits) and step (lower 7 bits) for decoding the block's samples.
:The first two bytes of each block are used to set the initial predictor (upper 9 bits) and step (lower 7 bits) for decoding the block's samples.
:The other 32 bytes consist of 64 samples stored as nibbles (half-bytes). In the case of stereo, all the nibbles in a block belong to the same channel (either all Left or all Right).
:The other 32 bytes consist of 64 samples stored as nibbles (half-bytes). In the case of stereo, all the nibbles in a block belong to the same channel (either all Left or all Right).
:Unlike for MS ADPCM, incomplete trailing blocks (if any) are not announced in any way: the final blocks are stored in their entirety, with no way to tell how much of it is actual data.
:Unlike for MS ADPCM, incomplete trailing blocks (if any) are not indicated in any way: the final blocks are stored in their entirety, with no way to tell how much of it is actual data.
:For this reason, identical sounds do not have the same sample count on PC (both retail and demo) and on Mac. As an example, here are the stats for some stereo sounds ("atm_cl05" ambient):
:For this reason, identical sounds do not have the same sample count on PC (both retail and demo) and on Mac. As an example, here are the stats for the main menu music:
{{divhide|Comparative table (click to unhide)}}
{{divhide|Main menu music a.k.a. "Oni Trailer"}}
{|
{|
|
|
{{Table}}
{{Table}}
!SNDD name (and frame count)
!SNDD name (and frame count)
!PC
!PC (retail and demo)
!Mac
!Mac
!difference
!difference
|-
|-
|
|
:'''SNDDatm_cl05_in'''
:'''SNDDmus_ot6'''
:100 frames = 1.6667 seconds
:415 frames = 6.9166667 seconds
:~= '''36750''' samples (@ 22.05 kHz)
:~= '''152512.5''' samples (@ 22.05 kHz)
|
|
:0x916C = 37228 = 36x1024 + 364 bytes
:0x25B0C = 154380 = 150x1024 + 780 bytes
:= 36x1012 + 352 = '''36784''' stereo samples
:= 150x1012 + 768 = '''152568''' stereo samples
:= 1.668208616780045 s (@ 22.05 kHz)
:= 6.919183673469388 s (@ 22.05 kHz)
|
|
:0x98BC = 39100 = 1150x34 bytes
:0x27940 = 162112 = 4768x34 bytes
:= 575x64 = '''36800''' stereo samples
:= 2384x64 = '''152576''' stereo samples
:= 1.668934240362812 s (@ 22.05 kHz)
:= 6.919546485260771 s (@ 22.05 kHz)
|
|
:As compared to the PC version of the SNDD,
:As compared to the PC version of the SNDD,
:the Mac version has 16 extra samples at the end
:the Mac version has 8 extra samples at the end
:(i.e., the last 8 bytes of the last two blocks).
:(i.e., the last 4 bytes of the last two blocks).
|-
|-
|
|
:'''SNDDatm_cl05_lp1'''
:'''SNDDmus_ot7'''
:897 frames = 14.95 seconds
:414 frames = 6.9 seconds
:~= '''329647.5''' samples (@ 22.05 kHz)
:~= '''152145''' samples (@ 22.05 kHz)
|
|
:0x5172A = 333610 = 325x1024 + 810 bytes
:0x25A3C = 154172 = 150x1024 + 572 bytes
:= 325x1012 + 798 = '''329698''' stereo samples
:= 150x1012 + 560 = '''152360''' stereo samples
:= 14.95229024943311 s (@ 22.05 kHz)
:= 6.909750566893424 s (@ 22.05 kHz)
|
|
:0x55880 = 350336 = 10304x34 bytes
:0x27874 = 161908 = 4762x34 bytes
:= 5152x64 = '''329728''' stereo samples
:= 2381x64 = '''152384''' stereo samples
:= 14.95365079365079 s (@ 22.05 kHz)
:= 6.910839002267574 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 30 extra samples at the end
:(i.e., the last 15 bytes of the last two blocks)
|-
|
:'''SNDDatm_cl05_lp2'''
:795 frames = 13.25 seconds
:~= '''292162.5''' samples (@ 22.05 kHz)
|
:0x48334 = 295732 = 288x1024 + 820 bytes
:= 288x1012 + 808 = '''292264''' stereo samples
:= 13.25460317460317 s (@ 22.05 kHz)
|
:0x4BD1C = 310556 = 9134x34 bytes
:= 4567x64 = '''292288''' stereo samples
:= 13.25569160997732 s (@ 22.05 kHz)
|
|
:As compared to the PC version of the SNDD,
:As compared to the PC version of the SNDD,
:the Mac version has 24 extra samples at the end  
:the Mac version has 24 extra samples at the end  
:(i.e., the last 12 bytes of the last two blocks)
:(i.e., the last 12 bytes of the last two blocks)
|-
|
:'''SNDDatm_cl05_lp3'''
:428 frames = 7.133333 seconds
:~= '''157290''' samples (@ 22.05 kHz)
|
:0x26F1 = 159506 = 155x1024 + 786 bytes
:= 155x1012 + 774 = '''157634''' stereo samples
:= 7.148934240362812 s (@ 22.05 kHz)
|
:0x28E80 = 167552 = 4928x34 bytes
:= 2464x64 = '''157696''' stereo samples
:= 7.151746031746032 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 62 extra samples at the end
:(i.e., the last 31 bytes of the last two blocks)
|-
|
:'''SNDDatm_cl05_lp4'''
:478 frames = 7.9666667 seconds
:~= '''175665''' samples (@ 22.05 kHz)
|
:0x2B7BE = 178110 = 173x1024 + 958 bytes
:= 173x1012 + 946 = '''176022''' stereo samples
:= 7.982857142857143 s (@ 22.05 kHz)
|
:0x2DABC = 187068 = 5502x34 bytes
:= 2751x64 = '''176064''' stereo samples
:= 7.984761904761905 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 42 extra samples at the end
:(i.e., the last 21 bytes of the last two blocks)
|-
|
:'''SNDDatm_cl05_out'''
:109 frames = 1.816667 seconds
:~= '''40057.5''' samples (@ 22.05 kHz)
|
:0x9E7A = 40570 = 39x1024 + 634 bytes
:= 39x1012 + 622 =  '''40090''' stereo samples
:= 1.818140589569161 s (@ 22.05 kHz)
|
:0xA68C = 42636 = 1254x34 bytes
:= 627x64 = '''40128''' stereo samples
:= 1.819863945578231 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 38 extra samples at the end
:(i.e., the last 19 bytes of the last two blocks)
|}
|}
|}
|}
{{divhide|end}}
{{divhide|end}}
By looking at the end of the Mac SNDDs (or the exported AIFF files), it can be confirmed that the extraneous samples are actually there, at the end of the last two 34-byte blocks (last Left block and last Right block). Unless the Mac engine has a very non-standard implementation of IMA4 ADPCM, there is no way to interrupt playback for the last blocks by cutting off the trailing samples (because they are no different from regular samples). This is one of the aspects that impact seamless playback of sequences (music or ambient tracks), see "looping issues" below.


Possibly Mac Oni just looks at the approximate length of each SNDD in frames (or game ticks, i.e., 1/60th of a second), which is listed in each SNDD's header and, once the announced frame count has been reached for the currently playing sound, starts playback on the next sound in the sequence. Depending on the hardware/software implementation of the audio pipelines, this logic can either interrupt the currently playing sound, or cause a slight overlap/crossfade between the current sound and the next. It is possible that PC retail Oni actually does the same, i.e., segments of a sequence are dispatched to the OS based on the frame count of the previous segment, rather than based on its actual play time (sample count). The early interrupt/crossfade is barely noticeable.
By looking at the end of the Mac SNDDs (or the exported AIFF files), it can be confirmed that the extraneous samples are actually there, at the end of the last two 34-byte blocks (last Left block and last Right block), with no way to interrupt playback upon reaching these trailing samples - because they are no different from regular samples.


Another theoretical possibility is that, in the case of IMA4 ADPCM, an illegal step index (outside the expected 0-88 range) is used to signify the end of the stream. Decoders typically resolve this by forcing out-of-bounds step indices into the 0-88 interval, but perhaps a custom decoder can interrupt the stream instead. However, this would be very non-standard behavior, and would only be feasible if the decompressed audio stream is put together inside Oni's engine, rather than deferred to the OS. Therefore it is more likely that Oni dispatches each segment to the OS based on the frame count; the OS receives the ADPCM-compressed data, decompresses it and plays it back; as for the overlap/crossfade/interruption of the currently playing segment, it is handled at OS level.
Also, from a careful examination of the sound stream that is actually played back by Oni in the main menu, it is clear that all the Oni engines (both Mac and PC) play back all the available data (including the "padding" of the fixed-size IMA4 blocks) before switching to the next segment. The frame count (number of game ticks) is ignored or used only as an indication (e.g., for approximate cueing in [[BSL]]).


This uninterrupted playback of fixed-size IMA4 blocks is one of the aspects that impact seamless playback of sound sequences in Mac Oni (music or ambient tracks). See [[OBD:SNDD#Looping_issues|"Looping Issues"]] below.
;NOTE
:Musically, the two segments of the main menu music correspond to the same duration (four bars of a 4:4 beat). However, somewhat suprisingly, the two segments don't have the same sample count - or even the same frame count (in game ticks) -, not even when comparing the two sounds on the same platform. That means that, even on PC where the playback is nearly seamless, we are actually hearing musical loops of unequal length, ending 10 milliseconds early or late, and it still sounds OK.


----
----
==Exporting and importing tips==
==Exporting and importing tips==
To create a wav/aif file one needs to write a file header like below and then write the contents of the raw data part.
To create a wav/aif file one needs to write a file header like below and then write the contents of the raw data part.
Line 281: Line 216:
As detailed above, ADPCM data is stored in blocks, but the actual sound data does not necessarily end exactly at the end of a block. This is true both for MS ADPCM (PC retail or demo) and IMA4 ADPCM (Mac), but is especially noticeable for the comparatively large blocks of MS ADPCM, where the padding can be as large as ~1010 samples, i.e., a ~46-millisecond silence in the case of 22.05 kHz (for IMA4, the biggest possible gap is 63 samples, or ~3 milliseconds).
As detailed above, ADPCM data is stored in blocks, but the actual sound data does not necessarily end exactly at the end of a block. This is true both for MS ADPCM (PC retail or demo) and IMA4 ADPCM (Mac), but is especially noticeable for the comparatively large blocks of MS ADPCM, where the padding can be as large as ~1010 samples, i.e., a ~46-millisecond silence in the case of 22.05 kHz (for IMA4, the biggest possible gap is 63 samples, or ~3 milliseconds).
===MS ADPCM===
===MS ADPCM===
Although the final block of a MS ADPCM SNDD file (PC retail) is stored in incomplete form (with only the actual samples and no padding), the standard decoding behavior (e.g., in an audio editor) is to automatically add the padding up to the end of the last block of an ADPCM-compressed WAV. Depending on the audio-editing tool, this can create a silence or some "bad data" at the end of the imported audio, which can be a problem if one wants to join SNDDs that are supposed to play seamlessly one after another (e.g., a musical or ambient sequence).  
Although the final block of a MS ADPCM SNDD file (PC retail) is stored in incomplete form (with only the actual samples and no padding), the standard decoding behavior when loading an ADPCM-compressed WAV (e.g., in a non-destructive audio program) is to assume full-sized blocks, with padding up to the end of the last block. Depending on the audio program, this can create a silence or some "bad data" at the end of the imported audio, which can be a problem if one wants to join SNDDs that are supposed to play seamlessly one after another (e.g., a musical or ambient sequence).  


As a workaround, one can preprocess .wav files with some tools that are more flexible about incomplete MS ADPCM blocks:
As a workaround, one can preprocess .wav files with some tools that can handle incomplete MS ADPCM blocks and convert to a less ambiguous format:
*For [http://sox.sourceforge.net/ Sox], padding is disabled by default when joining several files.
*For [http://sox.sourceforge.net/ Sox], padding is disabled by default when joining several files.
*For [https://www.ffmpeg.org/download.html ffmpeg], padding can be disabled as an optional setting.
*For [https://www.ffmpeg.org/download.html FFmpeg], padding can be disabled as an optional setting.
So, you'd either join the .wav files in Sox or FFmpeg, or convert them, e.g., to uncompressed PCM, and then import them into a fancy audio tool.


As an actual solution, the .wav file should be made compliant with RIFF WAVE standards, i.e., the last block should be padded to its full size, and a "fact" section should be used to specify the actual number of samples. This is implemented in OniSplit v 0.9.###
As an actual solution, the .wav file should be made compliant with RIFF WAVE standards, i.e., the last block should be padded to its full size, and a "fact" section should be used to specify the actual number of samples. This is implemented in OniSplit v 0.9.###
Line 294: Line 230:
===IMA ADPCM===
===IMA ADPCM===
====Padding====
====Padding====
In the case of IMA ADPCM, the padding is actually present in the stored audio, so it is impossible (both for OniSplit and for a third-party converter) to automatically trim it down to just the relevant audio data. In fact, just by looking at the Mac SNDD itself, there is no way to tell how many of the trailing samples need to be cut for a truly seamless transition.
In the case of IMA ADPCM, the padding is actually present in the stored audio, so it is impossible (both for OniSplit and for a third-party converter) to automatically trim it down to just the relevant audio data. In fact, just by looking at the Mac SNDD itself, there is no way to tell how many of the trailing samples need to be cut for a truly seamless transition (for one thing, the trailing samples are not flat zero).
 
As a workaround/solution, the correct sample count of a Mac SNDD can be looked up in a PC counterpart (always available, since we're only talking of music/ambients/sirens, which are neither localized nor sampled at 44.1 kHz), and then used to trim the .aif file in FFmpeg, while converting to .wav (either PCM or ADPCM). However, it's easier (and more reliable) to just grab a PC retail copy of Oni and extract the MS ADPCM sounds.
 


There are two solutions - an approximate one and an exact one:
#As an approximation, look up the frame count announced in the SNDD's header (using a hex viewer or an XML dump), divide that by 60 to get the length of the clip in seconds, and multiply by the sample rate 22.05 kHz. You will get the number of samples (and the corresponding delay in seconds) that are actually played back by Mac Oni before starting the next sound in the sequence. You can then replicate this delay with ffmpeg, Sox, or the audio editor of your choice. A cross-fade between the two clips in the overlapping region should sound best. You can also examine the samples near the approximate transition time, and "manually" determine where the actual samples end and the padding begins.
#As an exact solution, look up the sample count of an equivalent MS ADPCM file from a PC version of Oni. Padding should only be a problem for non-localized music and ambients, so the language version shouldn't matter. The electric "zap" sounds (which are sampled at 44.1 kHz in PC retail Oni) are also not loopable, so you should be able to find a 22.05 kHz sound with a intuitive sample count, similar to the Mac version. It will be somewhat smaller than the raw sample count of the IMA4 ADPCM, because of the padding (see the atm_cl05 example above for a comparison). Once you know the actual sample count, use ffmpeg to convert the .aif file to .wav (either PCM or ADPCM), keeping only the actual samples and trimming out the padding. Then, use Sox or ffmpeg to seamlessly join the .wav files as you would for regular MS ADPCM files (see above).
Of course, you can just grab a PC retail copy of Oni and extract the MS ADPCM sounds directly from there.
====Initial transient====
====Initial transient====
The biggest problem with seamless playback of Mac SNDDs (for music and ambient tracks) is that - even if you figure out the correct length of each segment - the waveform of each next segment builds up from zero over ~7 samples, instead of picking up where the previous segment left. This introduces about 0.3 milliseconds of silence, and an audible discontinuity in the waveform, even if the two segments are lined up properly. The values of those initial samples is not recoverable, so again it is recommended to turn to a PC version of Oni.
The biggest problem with seamless playback of Mac SNDDs (for music and ambient tracks) is that - even if you figure out the correct length of each segment - the waveform of each next segment does not pick up where the previous segment left (or should have left) - instead it builds up from zero over ~7 samples. This introduces about 0.3 milliseconds of silence, and an audible discontinuity in the waveform, even if the two segments are lined up properly.
====Role of frame count on Mac====
 
It has been verified (on the main menu music) that in PC Oni (both demo and retail) SNDDs are looped/chained accurately based on the actual sample count (and not on an approximate number of game ticks). Mac Oni probably ''does'' use game ticks, ending each segment slightly early. This eliminates pops that would be caused by a full playback of the IMA4 padding at the end of a segment, followed by the initial transient of the next segment. Early segment end would also be perceived as either a slight pop or a slightly "rushed" beat, but ingame it would be barely noticeable. If a Mac user can record his/her main menu theme playing for half a minute or so, then the resulting audio would be sufficient to validate or invalidate the "early cut" hypothesis.
The values of those initial samples is not recoverable (unlike the padding at the end of SNDDs, which can be trimmed down). Therefore, if working with sound samples extracted from Oni, it is recommended to turn to a PC version's SNDDs.


For what it's worth, the two segments of the main menu theme, '''SNDDmus_ot6.aif''' and '''SNDDmus_ot7.aif''' do ''not'' have the exact same duration (sample count) - and not even the same frame count (415 frames for '''SNDDmus_ot6''' vs 414 frames for '''SNDDmus_ot7''') -, although musically they're both supposed to consist of four 4:4 bars. So, even for the main menu theme, and even on PC where playback is seamless (no dropped samples), the musical segments themselves can have wrong timing at the end (one tick early or late), and you really can't tell that anything is off:
{{divhide|Main menu theme a.k.a. "Oni Trailer"}}
{|
|
{{Table}}
!SNDD name (and frame count)
!PC
!Mac
!difference
|-
|
:'''SNDDmus_ot6'''
:415 frames = 6.9166667 seconds
:~= '''152512.5''' samples (@ 22.05 kHz)
|
:0x25B0C = 154380 = 150x1024 + 780 bytes
:= 150x1012 + 768 = '''152568''' stereo samples
:= 6.919183673469388 s (@ 22.05 kHz)
|
:0x27940 = 162112 = 4768x34 bytes
:= 2384x64 = '''152576''' stereo samples
:= 6.919546485260771 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 8 extra samples at the end
:(i.e., the last 4 bytes of the last two blocks).
|-
|
:'''SNDDmus_ot7'''
414 frames = 6.9 seconds
:~= '''152145''' samples (@ 22.05 kHz)
|
:0x25A3C = 154172 = 150x1024 + 572 bytes
:= 150x1012 + 560 = '''152360''' stereo samples
:= 6.909750566893424 s (@ 22.05 kHz)
|
:0x27874 = 161908 = 4762x34 bytes
:= 2381x64 = '''152384''' stereo samples
:= 6.910839002267574 s (@ 22.05 kHz)
|
:As compared to the PC version of the SNDD,
:the Mac version has 24 extra samples at the end
:(i.e., the last 12 bytes of the last two blocks)
|}
|}
{{divhide|end}}


==PCM export and PC demo detection==
==PCM export and PC demo detection==
Line 359: Line 248:
Note that transcoding (between IMA4 and MS ADPCM) and encoding is not implemented at this point. So '''-extract:aif''' will not work on PC SNDDs, '''-extract:wav''' will not work on Mac SNDDs, and '''-create''' will only work on sound files that use the correct codec and sample rate supported by the PC retail/demo or Mac Oni engine.
Note that transcoding (between IMA4 and MS ADPCM) and encoding is not implemented at this point. So '''-extract:aif''' will not work on PC SNDDs, '''-extract:wav''' will not work on Mac SNDDs, and '''-create''' will only work on sound files that use the correct codec and sample rate supported by the PC retail/demo or Mac Oni engine.


Importing SNDDs for PC demo (with short .dat part and MS ADPCM in the .raw part) is also not implemented yet. Last but not least, PC retail apparently supports uncompressed PCM sounds, but they need to be tested in the engine first. Possibly ADPCM encoding/transcoding will be implemented at some point, too.
Importing SNDDs for PC demo (with a short .dat part and MS ADPCM in the .raw part) is also not implemented yet. Last but not least, PC retail apparently supports uncompressed PCM sounds, but they need to be tested in the engine first. Possibly ADPCM encoding/transcoding will be implemented at some point, too.


----
----
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/29636"