agree, +1
do you mean smth like "Try to find a high quality source rather than ripping a file from a streaming video website."?Cynplytholowazy wrote:
Suggest changing the "Try to find the highest quality source file available" to "Try to find higher quality source file available". Given the context is to stress the "rather than ripping a file from a streaming video website", make it clearer that it is to make sure the rule is interpreted more on the stress of not ripping from video sites instead of letting anyone confuse they have to find the highest quality source
+1 on the proposal as well tho
Yep that would sound better, just do "try to find a high quality source" should be enoughAJT wrote:
do you mean smth like "Try to find a high quality source rather than ripping a file from a streaming video website."?Cynplytholowazy wrote:
Suggest changing the "Try to find the highest quality source file available" to "Try to find higher quality source file available". Given the context is to stress the "rather than ripping a file from a streaming video website", make it clearer that it is to make sure the rule is interpreted more on the stress of not ripping from video sites instead of letting anyone confuse they have to find the highest quality source
+1 on the proposal as well tho
i agree the intention of that rule is prob just to get a high quality and not the absolute best cutoff 192 mp3, although i think the extra wording at the bottom might already solve this? i think changing to "high quality source" would be sensible too tho
iirc the main RC avoids mentioning external tools, but I think this could be covered in the recently added "tools" section at the start of the general RC:Doormat wrote:
Agreed +1
Also worth considering, you might want to add an addendum that says not to rely too much on spectrograms like spek. Different masterings/encoding settings can yield completely different spectrograms despite the audio quality being pretty much fine, e.g. anti-aliasing. It's always been pretty ridiculous how some people try to say that acceptable audio is trash just because of a jpeg of a graph; I prefer to determine audio quality with my ears, not my eyes
propose noffy wrote:
- A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
- A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.
Is it still planned to hard cap audio to 192kbps cuz it looks like there isn't a hard cap on the file size on your proposalNoffy wrote:
Writing a bunch of stuff like "reasonable" or "optional" in a rule is a mistake to begin with to be honest, they're not enforceable as a hard rule, besides applying it all the time, so it defeats the point of that phrasing.
It has the same problems as the current one
... I'm getting flashbacks to when I got told off when PRing a meta change for the same issue ahah
So I'd think we'd really need to re write it to avoid that kind of phrasing as much as possible.
- For better context:
The OLD old rule specified minimum 128kbps max 192 kbs. However this REQUIRED over encoding songs which did not have at least 128 quality audio in existence. This was changed to "reasonable" quality to avoid such contradictory practices but it looks like bad actors are making that backfire. Oof.propose noffy wrote:
- A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
- A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.
Reinstated 128 as general minimum, gets rid of reasonable quality all together. As long as they hit that minimum they're fine. This way the minimum exists without the old contradictory practice of up encoding songs that don't exist in at least 128.
Separates over encoding into its own rule so that it's easier to find and can be better specified.
- agree with "reasonable" being a bad word to use, i don't think "optional" has the same pitfall since to me it seems to categorically be specifying that you can't force a minor upgrade if the mapper doesn't want to, but regardless i think your suggested wording works to that end as well, so:Noffy wrote:
Writing a bunch of stuff like "reasonable" or "optional" in a rule is a mistake to begin with to be honest, they're not enforceable as a hard rule, besides applying it all the time, so it defeats the point of that phrasing.
It has the same problems as the current one
... I'm getting flashbacks to when I got told off when PRing a meta change for the same issue ahah
So I'd think we'd really need to re write it to avoid that kind of phrasing as much as possible.
- For better context:
The OLD old rule specified minimum 128kbps max 192 kbs. However this REQUIRED over encoding songs which did not have at least 128 quality audio in existence. This was changed to "reasonable" quality to avoid such contradictory practices but it looks like bad actors are making that backfire. Oof.propose noffy wrote:
- A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
- A song's audio file must not be encoded to a bit rate more than 20kbps higher than the original files.
Reinstated 128 as general minimum, gets rid of reasonable quality all together. As long as they hit that minimum they're fine. This way the minimum exists without the old contradictory practice of up encoding songs that don't exist in at least 128.
Separates over encoding into its own rule so that it's easier to find and can be better specified.
This is mostly fine. It is important to note that bitrate does not guarantee sound quality, so adding in a 128kbps minimum will not absolve people of the responsibility of needing listen and judge the tracks to actually be at that generally expected level of quality.
- A song's audio file and hitsound files must be of reasonable quality. When possible, a song's audio must be at least 128kbps in quality. When the minimum is not possible, use the highest sub-128kbps quality audio available.
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.
- A song's audio file must not be encoded to a bit rate more than or equal to 32kbps higher than the original files.
i've had bad experiences with soundcloud but from experience stuff like spotify and the auto-generated youtube videos for most songs are completely fine. i think the clause for streaming services generally doesn't need to exist, esp for platforms in where official sources (i.e. the original artist/s) have their music uploaded (spotify in particular since it is the king of popularity in the streaming space). Any time it is an issue is almost 100% of the time due to the source coming from a channel not associated with the music act. I've had exactly 1 example of spotify not providing a good mp3, and that was for olivia rodrigo's good 4 u.frozz wrote:
also speaking of audio rc changes, can we just delete the word "video" as well? so it will make less confusing because streaming isnt always about video, but audio as well (for example, soundcloud, spotify, youtube music, etc...) and to avoid loopholes about site that should be used to get audio
->Old rules wrote:
A beatmap's audio file must use the .mp3 or .ogg file format and have an average bit rate no greater than 192kbps.A song's audio file and hitsound files must be of reasonable quality. Try to find the highest quality source file available rather than ripping a file from a streaming video website. Songs should be normalised to their original release volumes and should not be encoded to a bit rate higher than their original files.
New rules wrote:
- The audio file of a beatmap must...
- ...use the .mp3 or .ogg file format.
- ...have an average bit rate no greater than 192 kbps.
- ...have an average bit rate no lower than 128 kbps, if such a source exists, otherwise use the highest quality available.
- ...not be encoded upwards from a lower bitrate.
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)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.