^ this sounds fine
@xandit with regards to normalising, some songs are intentionally loud or quiet (e.g. camellia songs), so forcing people to lower the volume there doesn’t really match up with what the artist wanted. At the same time, I personally don’t think it’s very harmful to raise audios volume (below the clipping point) if it’s abnormally quiet and seemingly unintentionally, but it is a trade off in terms of quality and it’s a hard line to draw, I don’t think your current wording works for that
Ephemeral wrote:
This is not fine. No degree of upward transcoding is permissible. If an original file is 96kbps and it is all that is available, the 96kbps file must be used on its own, as-is, and as per the clause written in the first quoted block. Running a track through encoder grit twice is an objectively worse experience for users.
i don’t know if we were talking about the same thing here since i wasn’t necessarily talking about exporting a file then exporting it again in a higher bitrate, i was kind of just talking about obtaining the file and then exporting it (i.e. because the “listed” bitrate is more than 192) in a higher bitrate than the song data actually supports (unless you’re referring to the first being run through an encoder as what occurred before the obtaining of the MP3 in the first place) i.e. all of the encoding issues getting DQed for are likely accidental rather than anyone actually thinking increasing the bitrate in audacity increases the quality (so it’s people not downcoding the bitrate when they should rather than them increasing it)
Regardless, that sounds fine to me under naxess’ proposal. The reason that was conjected was because of the only options for encoding above 128 in the most popular services being in 32kbps intervals, and a 10kbps overencode for example being very unrealistic and tedious to expect BNs to check for. Naxess’ phrasing is more hardline which should still get the job done, but I really doubt people are going to go and search for overencodes less than that value anyway (no-one does currently)
furthermore there was actually sizable discontent over the current overencoding rule since people weren’t actually sure what it was for and expressed that mp3s sounded exactly the same to them before and after fixing (which makes sense, since the same amount of data in the song would exist after lowering it, but with less wasted filesize) and hence it was understood that it was intended to limit filesize bloat rather than actually affect anyone’s gameplay experience, but I wouldn’t call myself an expert on the matter so
@frozz I don’t think that’s what the rule was meant to do, it’s implying to not use yt rips (YouTube to MP3 website converter type beat), which is already slightly outdated since you can rip in decent quality with command lines as kite has explained. Regardless, that part isn’t even in the current proposal anymore so yeah
[quote=“Ephemeral”]
I think a lot of people in this thread think this will stop the spate of disqualifications over audio quality in its tracks - it might slow some of it down, but it definitely isn't going to stop the notion from happening again. [/quote]
^ hard agree, can’t stress this enough. overencoding will still be a thing that people could QAH for, and people may still suggest upgrading to 192 quality if the map is using 128 - if these scenarios occur I don’t want there to be any harassment or spamming on either side since that just makes these threads way more of a headache than necessary.