sounds perfect +111 this is a really needed change after the recent unnecessary reports on qualified maps
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.
I am fine with this with the sole addition of:Naxess wrote:
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.
This doesn't take us very far from what already exists (outside of wording it nominally better, good call there) but does importantly outline the "acceptable quality" requirement for audio, which absolutely needs to stay.Addition wrote:
- The audio file of a beatmap must...
- ...use the .mp3 or .ogg file format.
- ...be of acceptable listening quality without any basic audio enhancements applied (no bass boosting, excessive amplification)
- ...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.
also slightly reworded eph's addition (assuming i understood it correctly). i understand the problems with using terms like "acceptable" but i also cant think of a scenario where it could cause issuesUpdated wrote:
- The audio file of a beatmap must...
- ...use the .mp3 or .ogg file format.
- ...be of acceptable listening quality while avoiding basic audio enhancements such as bass boosting or excessive amplification, unless purposely done by the artist. This applies to hitsound files as well.
- ...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.
New rule 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.
This also spells out that "reasonable quality" means to actually just listen to determine if it sounds ok.New guideline wrote:
- The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is obviously not intended by the artist. Simply listen to the audio for this and avoid relying on spectrograms or waveforms.
edit: removed "obviously" from the first sentence too its not neededNew guideline wrote:
- The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is not intended by the artist. Listen to the audio instead of just relying on software to detect these kind of issues.
Don't think that whole paragraph on listening to the audio is needed.Burak wrote:
I agree with Naxess' suggestion and I tried to simplify a little bit so it doesn't sound too nerdy/tutorial-like as ajt mentioned:edit: removed "obviously" from the first sentence too its not neededNew guideline wrote:
- The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is not intended by the artist. Listen to the audio instead of just relying on software to detect these kind of issues.
Redrafted slightly, thoughts?Naxess wrote:
community/forums/posts/8563364
New rule 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.
With regards to the adjective in brackets being superfluous or not, I think it could help in terms of indicating that you should just use common sense here rather than going on some CIA research quest to determine what was intentional in every file, although I don't think it makes much of a differenceNew guideline wrote:
- The audio file and hitsound files of a beatmap should not feature any audible and unwarranted sound distortions, like clipping, muffling, or crackling that is [clearly/obviously] not intended by the artist. This is best determined by listening to the audio, rather than using software on its own.
Agree with the [clearly/obviously] stuff, I think that helps to not give people the wrong idea about how strict that part of the rule is.AJT wrote:
Redrafted slightly, thoughts?