Re: 44.1 kHz is slowly reaching its end
Posted: Mon Jan 22, 2018 6:45 pm
You can run his script and hear for yourself.loxstep wrote:Though I'm still not worried about it if the difference is inaudible.
You can run his script and hear for yourself.loxstep wrote:Though I'm still not worried about it if the difference is inaudible.
I did run the script. Maybe I'm interpreting the results wrong. The original file and the 100th iteration of resampling sound identical to me. If I can't tell the difference after 100 times, I'm not worried about resampling something once.Lyberta wrote:You can run his script and hear for yourself.loxstep wrote:Though I'm still not worried about it if the difference is inaudible.
I think that the entity of the error might also depend on the resampler algorithm (so on sox version, in this case) but also on how the software was compiled, as I guess it could mean that floating point operation errors get propagated in a different way if the underlying assembler is different.Markus wrote:Hm, hard to tell. Probably caused by the resamplers filter or something, this would need some deeper investigation like reading/debugging the sox source. Maybe other resamplers don't do it. But that's just unreliable guessing.
On a rigorous mathematical standpoint, the two time series will compound as observations of two random variables. So we will see a change in the statistics of the noise. For real random noise. We are stuck in pseudo-random world for computers, but provided that the seed is different it should be pretty much the same as real random.forestandgarden wrote:Now between 2 white noise signals of same amplitude, the way peaks and valleys meet is absolutely random, you have to take an average of all possibilities, and between 0 and x2, that is: x1, your two noise signals are mixed, but the level hasn't changed.
Code: Select all
% How many samples of noise? This will be one second of noise at 96000 kHz
% sample rate:
timeSeriesLength = 96000;
% We generate two differet random noise sequences with 0 mean.
x = 2.0 * rand(timeSeriesLength, 1) - 1.0;
y = 2.0 * rand(timeSeriesLength, 1) - 1.0;
% Now we sum them:
z = x + y;
% And we calculate their RMS level: the dB level of their RMS value.
xLevel = 20.0 * log10(sqrt(mean(x.^2)));
yLevel = 20.0 * log10(sqrt(mean(y.^2)));
zLevel = 20.0 * log10(sqrt(mean(z.^2)));
% Display to the user, up to 2 digits.
disp(['Level of x signal = ' num2str(xLevel, 2) ' dB RMS (x is random noise)']);
disp(['Level of y signal = ' num2str(yLevel, 2) ' dB RMS (y is other random noise)']);
disp(['Level of z signal = ' num2str(zLevel, 2) ' dB RMS (z = x + y)']);
Code: Select all
Level of x signal = -4.8 dB RMS (x is random noise)
Level of y signal = -4.8 dB RMS (y is other random noise)
Level of z signal = -1.8 dB RMS (z = x + y)
As long as your original signal is band limited to 4 kHz that will most likely work just as good.42low wrote: I sometimes still even use 8Khz (in good quality that is).
For particular sound purposes which need good quality but small files.
Yes, human speech is usually band limited in 4 kHz - 5 kHz (although it can stretch to 7 kHz, but the most if it is within 4 kHz), so 8 kHz sampling rate works OK, as it limits the bandwidth of what you record up to 4 kHz.42low wrote: My personal experience and oppinion is that 8khz (IMA ADPCM codec) is the lowest to keep recognizable sounds (like voices). Below that, with 4khz everything is going to sound like telephone.
Considering that its patents expired recently and it is now a free format, I expect a small surge in popularity of it.protozone wrote:I sure hope MP3 dies before 44.1
Wow, that's a good point. You're right. I suppose on account of that, it will be here for another 13 yearsLyberta wrote:Considering that its patents expired recently and it is now a free format, I expect a small surge in popularity of it.protozone wrote:I sure hope MP3 dies before 44.1
Forget it, 8 track/floppy disks/VHS/zip drives/cassettes will never die. Otherwise a lot of software/music/movies could be thrown away.42low wrote:Forget it. It will never die. Otherwise a lot off players could be thrown away.protozone wrote:I sure hope MP3 dies before 44.1
WAV can have 65535 channels of 65535 bit at 4,294,967,295 Hz (4.3 gigahertz). The byterate would be 2.3 exabytes (2,300,000 terabytes) per second.protozone wrote:Formats are kinda fun, though. When you find something good. I even use TTA sometimes (TrueType Audio). It's brilliant. You could have 256 channels of 96 kHz lossless PCM in that one file, I think.
Right, I was mostly being silly. Digital formats are very different from the physical media. Ultimately I think that produced music will be distributed in a different format, but players will continue to support mp3 as a legacy format.42low wrote:Nothing will totally die.
Wow, that's amazing.Lyberta wrote:WAV can have 65535 channels of 65535 bit at 4,294,967,295 Hz (4.3 gigahertz). The byterate would be 2.3 exabytes (2,300,000 terabytes) per second.protozone wrote:Formats are kinda fun, though. When you find something good. I even use TTA sometimes (TrueType Audio). It's brilliant. You could have 256 channels of 96 kHz lossless PCM in that one file, I think.
Actually, it was since the beginning. Number of channels and bit depth are stored as 16 bit integers and sample rate as 32 bit one. The main limitation is that the file size is stored as 32 bit integer which limits it at 4 GiB. WAV64 fixes this.protozone wrote:Wow, that's amazing.
I didn't realise it had progressed to that level of sophistication.
It's been a while since I've read about that type of thing. Is that broadcast WAV format, or just regular WAV?