4 ms·
Okay, I got nerd sniped [0]. Here's the script I've made: https://gist.github.com/paskozdilar/6095fe73c80ad21fda3f518177699149 This isn't an exact method,
by bheadmaster 2y ago
Okay, I got nerd sniped [0]. Here's the script I've made:
https://gist.github.com/paskozdilar/6095fe73c80ad21fda3f518177699149
This isn't an exact method, so it will only print bitrates and their respective "difference" parameter. In general, as the difference parameter rises, you're more likely to have reached the "true" mp3 quality, and a sudden jump in difference parameter is an almost certain indicator of true quality.
E.g. for a System Of A Down song "36", encoded at 320kbps, I get the following output:
user@hostname:~/temp$ ./main.sh 36.mp3
320: 0.075272
256: 0.121475
224: 0.160858
192: 0.193726
160: 0.237717
128: 0.308029
112: 0.363953
96: 0.409012
80: 0.454941
64: 0.578598
56: 1.105850
48: 1.081100
40: 0.629898
32: 1.223129
Here, we have a jump immediately after 320kbps, which shows that this file is true 320kbps.
When I compressed the song to 64kbps and then re-compressed it to 320kbps, I get this result:
user@hostname:~/temp$ ./main.sh 36-reencoded.mp3
320: 0.146484
256: 0.146484
224: 0.146484
192: 0.146484
160: 0.146484
128: 0.146957
112: 0.178665
96: 0.210373
80: 0.175171
64: 0.211609
56: 1.054886
48: 0.944687
40: 0.505280
32: 0.852020
As we can see, the most significant jump happens from 64kbps to 56kbps, which confirms that this file's true bitrate is indeed 64kbps.
Though, as sibling comment says, it's not confirmed that this kind of process works across encoders. I think that it should, because MP3 as a lossy codec mostly removes higher frequencies, and re-encoding compressed signal with same bitrate should remove less higher frequencies, because there are less to begin with. But I have no way to confirm - I'd need an array of encoders to actually verify this.
[0] https://xkcd.com/356/ https://xkcd.com/356/
- tambourine_man 2y agoWhat an awesome thread. Someone posts a reasonable assumption, another one quickly validates it with a simple script. This is why I love Hacker News.
- waterhouse 2y agoIf you check the usernames, the one who suggested and the one who followed up are the same person. :-)
- tambourine_man 2y agoOMG, you’re right. They nerdsnipped themselves.
- water-data-dude 2y agoA tale as old as time, hahaha
- qwertygnu 2y agoLooks like there's a pretty big jump at 56 in the first version as well.
- geor9e 2y agoThat sounds right. It should go from all small steps to all big steps. Every step past the real bitrate is shucking data humans can't hear well, more and more aggressively. Every step before the real bitrate is looking for data to shuck but not finding it. I just realized, social media sites may do something similar to save space. I've noticed whenever I upscale my video resolution, they aren't fooled. At first the video will be hosted in 4k, but later that option disappears, and only the 1080P and lower resolutions are left. But sharp footage from my real 4k camera stays hosted at 4k. I figured they must take a screenshot and determine the blurriness, but now I think they might just look at those re-encoding stats they already have.
- bheadmaster 2y agoSeems that way. Probably because I'm using Maximum delta of the difference as the metric. Using some intergral-like function (e.g. average amplitude of all samples) would probably yield better results, but I have a hard time getting any useful data out of this script on my home computer. Weird. I'll possibly work more on this topic, maybe I'll make a HN post.
- ggeorgovassilis 2y agoThat's more than I ever could have asked for. Amazing work, thank you so much! What's the script's license?
- bheadmaster 2y ago> What's the script's license? For legal purposes, let's say GNU All-permissive License. I promise not to sue :')