![]() ![]() It's also kind of like the difference between decoding an h.264 video at 720p 30fps vs 720p 60fps - for specifically the decoding (because obviously you'd ideally want a higher bitrate and therefore larger file size for 60fps), yeah it used to be quite the difference in terms of hardware demands, but nowadays the difference for decoding is a drop in the bucket in terms of demands due to hardware decoders, but even older mobile CPUs are fast enough to software decode it nowadays (you have to get to Pentium 4/Athlon XP/1st gen Atom levels of bad IPC at the usual 1+GHz clockrates before it becomes a problem).Ī more apt analogy is probably how PC gamers used to select 16bit color for better performance back in the late 90s, but nowadays you might as well just render everything at 24bit color/32bit color since the performance difference is practically non-existent on even the weakest of Intel integrated GPUs. So I would imagine that whether iOS would allow 24bit or if it requires 16bit from apps is the bottleneck here.Īnd yes 16bit integer is "reasonable" but it's kind like having your monitor set to a 60Hz refresh rate back in the days of CRTs rather than 75Hz despite AFAIK basically all CRT monitors also supporting 75Hz (which of course on a CRT also reduced the flicker) - outside of actually needing to actually put in a bit of time to change it, there's not really much (if any?) downside except maybe ever so slightly increased processing time? (at least for floating point audio I'm not even sure if 24bit integer audio would use more CPU than 16bit integer audio when all of these CPUs are at least 32bit architectures anyway unless the compiler was specifically able to fit two 16bit integer operations within a single 32bit integer operation). So I was slightly off - iOS uses 24bit integer and 16bit integer, but possibly for different things? My major lack of experience with Apple stuff is making me uncertain as to what they're actually referring to:īut Android by comparison is straight-up 32float nowadays: ![]() Comparing the 16bit FLAC to the recording of the 24bit FLAC returned an amplify value of 50dB with "New peak" listed as -13dB (so basically 63dB). ![]() ![]() To compare the recording to the according FLAC I lined up the waveforms to the exact identical sample, inverted one of the waveforms, mixed the two together to a new waveform, and then looked at the value listed in "amplify" to see the difference - the larger the value, the smaller the difference.Ĭomparing the 16bit FLAC to its according recording returned an amplify value of "Infinity" (identical) while comparing the 24bit FLAC to its according recording resulted in an amplify value of 50dB with "New peak" listed as -40dB (so basically 90dB). All volume sliders in Windows, Audacity, and Ren'Py were set to 100%. For recording I just used Audacity (though admittedly an older version from before the UI change - v2.1.2) set to record "speakers" on my Xonar DS sound card which was similarly set to 48kHz 24bit. This could arguably make sense if it just always truncated or down-sampled everything to 16bit audio output, but doesn't explain why the resulting audio render seemed to still be so different from the 16bit equivalent.įor reference I took a 192kHz 24bit copy of Simon & Garfunkel's "The Boxer" and downsampled it using foobar2000 and the SoX plug to both 48kHz 24bit and 48kHz 16bit. I mean, if Ren'Py doesn't handle 24bit audio output then I wouldn't expect it to even support 24bit FLAC files, and yet it does. yet, when actually doing an audio recording to compare how Ren'Py renders the audio compared to the source files, only the recording for the 16bit FLAC ended up being 100% identical to the according FLAC file while the recording for 24bit FLAC ended up being a teeny bit different - almost like it was being reduced in bit depth to something between 24bit and 16bit, like 20bit or something.Īgain, I realize this is super-duper unimportant, but the inconsistency in audio rendering makes me wonder if there's a bug or something. I know I know, this is some super-duper OCD audiophile crap that nobody in their right mind should ever care about, but I'm concerned about the possibility of a bug in how Ren'Py handles greater-than-16bit audio (which is actually pretty common with lossy formats since the likes of MP3, Vorbis, and Opus store their audio data as floating point).īasically, while doing some audio tests to see how Ren'Py handles different audio formats, I discovered that it supports both 16bit and 24bit FLAC ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |