3DS Theme BCSTMs

Alright, so recently the topic about sample rates, total samples, and 3ds theme bcstm limits came up in the themeplaza discord. Since this sort of thing was up my alley the first time, it kind of rekindled some of my interest and I wanted to take a closer look at the absolute limits of quality that could be achieved with a 3ds theme bcstm (henceforth just referred to as bcstm). Like before, this is going to be a breakdown of the numbers I used and what I eventually came up with.

tl;dr of the steps taken:
- Get a ratio between the size of the bcstm and the wav file
- Use that ratio and the max bcstm limit to determine the maximum size of the wav file possible
- Get a ratio between the size of the wav file and the total number of samples
- Use that ratio and the max wav limit to determine the maximum number of samples possible
- End up with 2947822 samples to be used instead of 2922920

To get some basic background of the setup:
- The audio used was generated with audacity as stereo DTMF tones for 60 seconds @44100hz
- It's exported as a signed 16-bit PCM wav file

Now, for those that don't know too much about audio, the simple take-away is that no matter what the audio clip may be (loud, soft, rock music, rain drops), as long as it is EXACTLY 60 seconds @44.1kHz and saved as a signed 16-bit PCM wav file, the resulting .wav file will always be the same size (10,584,044 bytes wav). Similarly, the size of the bcstm will also be the same final size once converted from the aforementioned .wav file (3025856 bytes bcstm).

From the two previously mentioned numbers, we can extrapolate a ratio between .wav files and .bcstm files:
- Ratio (wav / bcstm) = (10584044 wav.bytes) / (3025856 bcstm.bytes) => 3.497867710822987 wav / bcstm bytes

We can also extrapolate a ratio between the size of the .wav file and the number of samples (number shown in audacity):
- Ratio (samples / wav) = (2646000 samples) / (10584044 wav.bytes) => 0.2499989606997099 samples / wav bytes

Using the ratio between bcstm/wav and the max bcstm limit, we calculate the maximum size our wav file will be:
- (3.497867710822987 wav / bcstm.bytes) * (3371008 bcstm.bytes) => 11791340.03612598 wav.bytes

Using the ratio between samples/wav and the max wav limit, we calculate the maximum number of samples our wav file can have:
- (0.2499989606997099 samples / wav.bytes) * (11791340.03612598 wav.bytes) => 2947822.754288375 samples

Now this total number of samples is the maximum number of samples we can fit and still remain within the bcstm limit, and due to samples having to be whole, we can drop the decimal and be left with 2947822 samples. This number can replace my previously stated 2922920 in my previous blogpost on the topic.

Bringing things back into context, when making a bcstm where the loop must be perfect (or relatively close), this means that the total duration of any given clip can be considered static, leaving our only controllable variable being the sample rate of the audio to control the final number of samples the audio will have. So, we can once again calculate the sample rate using our new number, provided we keep the seconds as accurate as possible (0.001 seconds is the finest increment we can get from audacity):
- Sample rate = (2947822 samples) / (duration of audio clip in seconds)



For mid-audio loops, things are a little more complex, which currently eludes me on a good way for solving how to come up with something that can provide the optimal sample rate since there are factors that seem to rely on the total number of samples or duration of the specific clip. As a list for the things that I have noticed without coming to any conclusions:
- When increasing the length of the introductory section (having a later looping start position), a common pattern can be seen in which every 56 samples of starting positions, the size of the output will decrease by 64 bytes up until the size has decremented 255 steps (aka 16320 bytes) before jumping back to the maximum size that the clip can be given the constraints above.
- This maximum size CAN, and potentially WILL exceed the bcstm limit when using the ideal number of samples calculated above (2947822 samples) for any given mid-audio loop.
- The initial cycle of positions (1-56) can vary in size and depends on the samples/duration

We can still come up with a generalized solution that at least covers the worst case scenario, which would in turn cover all of the other possible scenarios, but this does come at the cost of ~16320 bytes of potential quality (which is honestly insignificant in all normal use-cases). Simply put, we can follow the same steps we performed above to determine roughly the number of samples to account for the extra 16320 bytes to prevent ourselves from going over. What we end up with is 14271 samples, which should be subtracted from the ideal total samples (2947822 samples).
- 2947822 samples - 14271 samples = 2933551 samples (roughly)

In practice, 2933551 samples is just slightly too close and (in my test case I ended up with a file that is 3371040 bytes), can go over the bcstm limit, so I revised the number with a bit of empirical testing to get a final number of 14331 samples, leaving us with a final ideal sample total of 2933491 samples.

Now, this value hasn't really been thoroughly tested or anything on different audio clips and it's not likely that anyone would come back to tell me their own findings on the matter. In summary, my new sample rate formulas (duration should be seconds up to the thousandths, ex. 0.001):
- Full Loop Sample Rate = (2947822 samples) / (duration in seconds)
- Mid-Audio Loop Sample Rate = (2933491 samples) / (duration in seconds)

Comments

There are no comments to display.

Blog entry information

Author
jurassicplayer
Views
582
Last update

More entries in Personal Blogs

More entries from jurassicplayer

General chit-chat
Help Users
  • No one is chatting at the moment.
    Psionic Roshambo @ Psionic Roshambo: Taylor Swift death metal AI cover please lol