Sounds.json cannot alter the randomized pitch or volume at which the game calls certain sound events
The bug
The game calls all sound events with certain variables (most notible pitch, but also volume and whether it is global or not).
These variables cannot be changed by resource packs in any way shape or form, despite the sounds.json having corresponding fields (per sound file in a sound event).
Steps to reproduce
- Place grass blocks, listening closely to the pitch of the sounds.
- Run /playsound block.grass.place master @s ~ ~ ~ 1 several times, listening closely to the pitch of the sounds.
- Observe the pitch is different, and as such the game calls the sound event with a pitch (0.8 in this case).
Expected result
The game would always call sound events with "default" parameters, and the sounds.json would handle said parameters with the fields in the sounds list/array.
Actual result
The pitch, volume and whether or not a sound is global are hardcoded and cannot be edited by resource packs.
Suggested change for when this gets fixed
To preserve the game's functionality of a pitch range, without having to create an event every single pitch, it might be good to give the pitch and volume options a min and max value, rather than only a single float.
{"name":"mob/zombie/hurt1",pitch:{min:0.7,max:1.3}
- Unresolved
user-f2760insomniac_lemon
- 51
- 26
- Confirmed
Low
- Platform
- Sound
- hardcoded mojang_internal_1 pitch resource-pack sound
13w42a - 24w10a
13w42a 13w42b 13w43a 1.7.1 1.7.2 13w47e 13w48a 13w48b 13w49a 1.7.3 1.7.4 14w04b 14w05b 14w06a 14w06b 14w07a 1.7.5 14w11b 1.7.9 14w17a 14w18a 14w20a 14w20b 14w21a 14w21b 1.8-pre1 1.8-pre3 1.8 1.8.1 1.8.3 1.8.7 1.8.8 15w31a 15w31c 15w32a 15w32b 15w32c 15w33a 15w33b 15w33c 15w34a 15w36b 15w36c 15w36d 15w37a 15w38a 15w38b 15w39a 15w39b 15w39c 15w40a 15w40b 15w41b 15w42a 15w43a 15w43c 15w44a 15w44b 15w45a 15w46a 15w47a 15w47b 15w47c 15w49a 15w49b 1.8.9 15w50a 15w51a 15w51b 16w02a 16w03a 16w04a 16w05a 16w05b 16w06a 16w07a 16w07b 1.9-pre1 1.9-pre2 1.9-pre3 1.9-pre4 1.9 1.9.4 16w20a 16w21a 16w21b 1.10-pre1 1.10.2 16w40a 1.12 1.12.1-pre1 1.12.2 18w19b 1.17 1.17.1 1.18.1 1.19 1.19.1-pre2 1.19.2 1.19.3 23w06a 1.19.4 1.20.1 1.20.2 23w42a 23w43b 1.20.4 24w10a
Created Issue:
RP Sound control through sounds.json: Pitch range cannot be altered
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"sounds": ["mob/zombie/infect"]}, "mob.zombie.infect": {"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]} }This worked, however, pitch shifting still occurs. I expected there to be a set pitch because a "pitch" parameter was set.
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch:2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionaly, this should also trickle down into /playsound as arguments as well.
- Unresolved
- Open
- Unconfirmed
- pitch, sound,
- 13w42a 13w42b
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"sounds": ["mob/zombie/infect"]}, "mob.zombie.infect": {"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]} }This worked, however, pitch shifting still occurs. I expected there to be a set pitch because a "pitch" parameter was set.
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionaly, this should also trickle down into /playsound as arguments as well.
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"sounds":["mob/zombie/infect"]},"mob.zombie.infect":{"category":"hostile","sounds":[{"type":"event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]} }This worked, however, pitch shifting still occurs. I expected there to be a set pitch because a "pitch" parameter was set.
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionaly, this should also trickle down into /playsound as arguments as well.
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/infect"]}, "zombie_unfect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/unfect"]}, "mob.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]}, "mob.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_unfect_nopitchchange"}]}, }This worked, however, pitch shifting still occurs (most notably with the "unfect" sound which slows down incredibly) . I expected there to be a set pitch because a "pitch" parameter was set. A pitch of 1.0 still allows for pitch changing, which (as stated for unfect) seems to be much more of an issue for longer sounds (unless unfect is just slowed down more often?).
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionaly, this should also trickle down into /playsound as arguments as well.
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/infect"]}, "zombie_unfect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/unfect"]}, "mob.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]}, "mob.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_unfect_nopitchchange"}]},}This worked, however, pitch shifting still occurs (most notably with the "unfect" sound which slows down incredibly) . I expected there to be a set pitch because a "pitch" parameter was set. A pitch of 1.0 still allows for pitch changing, which (as stated for unfect) seems to be much more of an issue for longer sounds (unless unfect is just slowed down more often?).
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionaly, this should also trickle down into /playsound as arguments as well.
Is this still a concern in the current Minecraft version 14w06b / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/infect"]}, "zombie_unfect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/unfect"]}, "mob.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]}, "mob.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_unfect_nopitchchange"}]} }This worked, however, pitch shifting still occurs (most notably with the "unfect" sound which slows down incredibly) . I expected there to be a set pitch because a "pitch" parameter was set. A pitch of 1.0 still allows for pitch changing, which (as stated for unfect) seems to be much more of an issue for longer sounds (unless unfect is just slowed down more often?).
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionally, this should also trickle down into /playsound as arguments as well.
EDIT: sounds.json for 15w43c demonstrating the issue.
{ "enttiy.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "block.piston.contract"}]}, "entity.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "entity.enderdragon.death"}]}, "entity.zombie.cure": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "entity.enderdragon.death"}]} }If you try to cure a bunch of villager zombies, the long ender dragon sound becomes incredibly long showing that it is changing the speed of the sound.
RP Sound control through sounds.json: Pitch range at which the game calls a sound event cannot be altered
RPSoundcontrol through sounds.json: Pitch range at which the game calls a sound eventcannot be alteredSounds.json cannot alter the pitch or volume at which the game calls a sound event
relates to
By default, most sounds have a random amount of pitch change to make them seem more natural/varied, like different sounds. With very long sounds, this is very annoying because it slows them down incredibly to the point where it is not understandable.
With the new sounds.json file, I thought I'd try to remove pitch changing:
sounds.json{ "zombie_infect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/infect"]}, "zombie_unfect_nopitchchange": {"replace":true,"sounds": ["mob/zombie/unfect"]}, "mob.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_infect_nopitchchange"}]}, "mob.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "zombie_unfect_nopitchchange"}]} }This worked, however, pitch shifting still occurs (most notably with the "unfect" sound which slows down incredibly) . I expected there to be a set pitch because a "pitch" parameter was set. A pitch of 1.0 still allows for pitch changing, which (as stated for unfect) seems to be much more of an issue for longer sounds (unless unfect is just slowed down more often?).
How it can be fixed: add more parameters related to pitch:
"min_pitch":0.5
"max_pitch":2.0Setting "pitch" without setting the min and max will assume the same number for all 3, resulting in the same pitch every time. If min and max are set, "pitch" will act as the average, with more of a change to be affected by a larger distance (for instance, with the min/max params above, using a pitch of 1.0 will usually result in a pitch of 1.0 or slightly higher).
Additionally, this should also trickle down into /playsound as arguments as well.
EDIT: sounds.json for 15w43c demonstrating the issue.
{ "enttiy.zombie.infect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "block.piston.contract"}]}, "entity.zombie.unfect": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "entity.enderdragon.death"}]}, "entity.zombie.cure": {"replace":true,"category": "hostile","sounds": [{"type": "event","pitch":1.0,"name": "entity.enderdragon.death"}]} }If you try to cure a bunch of villager zombies, the long ender dragon sound becomes incredibly long showing that it is changing the speed of the sound.
The bug
The game calls all sound events with certain variables (most notible pitch, but also volume and whether it is global or not).
These variables cannot be changed by resource packs in any way shape or form, despite the sounds.json having corresponding fields (per sound file in a sound event).Steps to reproduce
- Place grass blocks, listening closely to the pitch of the sounds.
- Run /playsound block.grass.place master @s ~ ~ ~ 1 several times, listening closely to the pitch of the sounds.
- Observe the pitch is different, and as such the game calls the sound event with a pitch (0.8 in this case).
Expected result
The game would always call sound events with "default" parameters, and the sounds.json would handle said parameters with the fields in the sounds list/array.
Actual result
The pitch, volume and whether or not a sound is global are hardcoded and cannot be edited by resource packs.
Suggested change for when this gets fixed
To preserve the game's functionality of a pitch range, without having to create an event every single pitch, it might be good to give the pitch and volume options a min and max value, rather than only a single float. ({{{"name":"mob/zombie/hurt1",pitch:
{min:0.7,max:1.3\}}}}
The bug
The game calls all sound events with certain variables (most notible pitch, but also volume and whether it is global or not).
These variables cannot be changed by resource packs in any way shape or form, despite the sounds.json having corresponding fields (per sound file in a sound event).Steps to reproduce
- Place grass blocks, listening closely to the pitch of the sounds.
- Run /playsound block.grass.place master @s ~ ~ ~ 1 several times, listening closely to the pitch of the sounds.
- Observe the pitch is different, and as such the game calls the sound event with a pitch (0.8 in this case).
Expected result
The game would always call sound events with "default" parameters, and the sounds.json would handle said parameters with the fields in the sounds list/array.
Actual result
The pitch, volume and whether or not a sound is global are hardcoded and cannot be edited by resource packs.
Suggested change for when this gets fixed
To preserve the game's functionality of a pitch range, without having to create an event every single pitch, it might be good to give the pitch and volume options a min and max value, rather than only a single float.
{min:0.7,max:1.3\}}({{{"name":"mob/zombie/hurt1",pitch:}}
The bug
The game calls all sound events with certain variables (most notible pitch, but also volume and whether it is global or not).
These variables cannot be changed by resource packs in any way shape or form, despite the sounds.json having corresponding fields (per sound file in a sound event).Steps to reproduce
- Place grass blocks, listening closely to the pitch of the sounds.
- Run /playsound block.grass.place master @s ~ ~ ~ 1 several times, listening closely to the pitch of the sounds.
- Observe the pitch is different, and as such the game calls the sound event with a pitch (0.8 in this case).
Expected result
The game would always call sound events with "default" parameters, and the sounds.json would handle said parameters with the fields in the sounds list/array.
Actual result
The pitch, volume and whether or not a sound is global are hardcoded and cannot be edited by resource packs.
Suggested change for when this gets fixed
To preserve the game's functionality of a pitch range, without having to create an event every single pitch, it might be good to give the pitch and volume options a min and max value, rather than only a single float.
{"name":"mob/zombie/hurt1",pitch:{min:0.7,max:1.3}
Sounds.json cannot alter the pitch or volume at which the game callsasound eventSounds.json cannot alter the randomized pitch or volume at which the game calls certain sound events
The game calls the place sound event at a certain pitch; if you change the sound event to use different sounds, the place sound (both by placement and playsound) have the sounds you set it to. It's just the pitch that is controlled by the game, and not the sounds.json (see also MC-36042).
TLDR: sound event is correct, game just plays it at a different pitch.
Seems to have been improved for the "unfect" sound in 14w17a, but is still an issue.
Attempting to override a creeper's fuse noise with
results in a sound that is ALWAYS incredibly slowed down, suggesting that the pitch for this sound is hardcoded to be slowed down.
Still an issue in 1.8.3.
A simpler way to put it is that pitch values are still hardcoded. Composed of:
Simply put, these hardcoded pitch/speed changes need to be removed and ported to the vanilla sound system. Example, at pitch 1.0 the creeper fuse should sound exactly like the TNT fuse, and the sound should immediately stop right when it explodes.
If default wants it at a lower pitch/speed then that should be defined in sounds.json to do so. Max and min values would solve hardcoded pitch change, even if at worst, you had to specify min and max of 1.0 to fully disable pitch change.
Even with this: https://twitter.com/_grum/status/654011400256360448 bringing sound changes to 15w43a, pitche variation is still very hardcoded
This will perhaps get looked at for 1.10, its a rather big change and I've not really found a nice way to handle it. It's the same for volume.
Postponed "for 1.10". Still an issue in 1.12.2. I've stopped working on my sound packs after discovering this.
Is this still an issue in 1.16.4?
Marty McFly please don't ask those types of questions. Those questions are reserved for moderators
Can confirm in 1.17
Confirmed in 1.19. This has been bugging me for YEARS, I've been trying to create a Team Fortress 2 resource pack but I can't replace many of the sounds I want because they just sound awful with the random pitch changes. Please fix this!
Watching this, want to replace the pop.ogg with the pickup sound from TLoZ:BoTW and pitch shifting in Audacity isn't working as it's either still too high or low pitched. Would love to see a fix to this old problem.
GOOD LORD, PLEASE FIX THIS ISSUE ALREADY! IT HAS BEEN 9 YEARS ALREADY!
Some sounds do not change pitch when you add in a {"pitch": 1.0}, but almost all of them STILL DOES! adding in {"min_pitch"} or {"max_pitch"} LITERALLY does NOT do anything at all.
This here does absolutely nothing. > {"entity.player.hurt": {"replace": true,"sounds": ["damage/hit1",
{"name": "damage/hit1","pitch": 1.0,"stream": true}]}
This actually works! > {"item.spyglass.use": {"replace": true,"sounds": ["item/spyglass/use",
{"name": "item/spyglass/use","pitch": 1.0,"stream": true}]}
Why does this only work for some sounds? Why is it VERY arbitrary? PLEASE just fix this already and give us the ability to change the pitch of all sounds through resource packs, we have been waiting patiently and you did ABSOLUTELY NOTHING.
I've rewritten the report to be a lot more concise, the problem at hand was getting bloated around by attempts of a non-valid format and more. This should be more straightforward.
The report may look more like a feature request now, but this was always on the gray area between issue and change request.
Syech Muhammad Zakkarria Al Razi There's a difference between the game calling the event with a pitch/volume, and the game calling an event that has a pitch and volume defined. The latter is located in sounds.json and can be changed by resource packs. It's the former that's the problem.
Also, please calm down, while this is a long standing issue, it's one that has good reason to be the way it is. Many, and I mean MANY sound events are re-used, but called on a different pitch/volume to change the effect of the sound; fixing this pretty much means splitting up every single usage into its own sound event.
Affects Version 1.20.2:
I've encountered this issue with volume levels, and it appears random, but probably isn't, If I'm right about why this is happening. It's also potentially the reason for all the other reported issues in this thread, but not for the reasons that other people might think. I know this is long, but please bear with me.
I added a sound to my sounds.json that was intended to completely overwrite an existing vanilla sound, and leave others alone:
{ "entity.villager.ambient": { "sounds": [ {"name":"mob/villager/idle1", "volume":0.1}, "mob/villager/idle2", "mob/villager/idle3" ], "subtitle": "subtitles.entity.villager.ambient" }What I noticed when I tested this sound was that the event would sometimes play the sound at my requested volume, but sometimes play the sound at full volume.
After cranking up the "weight" of that record to 50000 and hearing my requested volume each and every time, I now think I know why this is happening. Please correct me if I'm wrong.
The crux of the issue:
It seems to me that, when Minecraft builds the array of sounds for an event, it includes records from the "lower" pack for the same event, even if they refer to files of exactly the same filename in exactly the same location. What happens then is that, in my example at least, there are now two records for "idle1" in memory, and the game randomly chooses either of the two at runtime (because they both have equal weight.) When it chooses my record, it plays my file at my chosen volume. However, when it chooses the built-in Minecraft record, there is no volume specification, so it plays "idle1" at full volume. But since I've replaced "idle1" with a different .ogg file, Minecraft plays my sound with Minecraft's (hidden) default volume specification (and blasts my eardrums out in the process.) This is probably what has been happening with all the pitch issues as well.
One way for pack creators to resolve this on our end is to use "replace":true on the entire sound event but this destroys the ability to layer resource packs together properly, since every "higher" pack necessarily eliminates all sounds from the same event in "lower" packs, regardless of filename (or location.) In my case, that could mean that hundreds of sounds fail to play, despite having all different names from pack to pack. "replace":true is a nuclear explosion when a pistol would do.
Another way for a pack creator to resolve this is to pepper their sounds.json with massive "weight" quantities, but this means that to be compatible with one-another, every pack would need to have exactly the same weight specifications, or some packs would overtake others. My pack would outweigh yours if I had higher numbers (and vice-versa.)
Neither of the above are good solutions.
A possible solution:
Every .ogg file that can be triggered by a sound event should have one and only one json record in memory that can be chosen randomly by the game. There should never be conflicting json directives in memory. Only the highest-level pack should be the source of truth. All identical records from lower packs should be overwritten by that top-level record (on an individual basis.) We should no longer have to squash entire sound events in potentially multiple packs with "replace":true in order to replace individual sounds, nor should we be required to hack the system by using astronomically high "weight" for everything (which isn't even a guarantee.)
This was the behavior I expected, which is why I went looking on your bug tracker when it did something else.
Thanks for listening. I hope you all have a wonderful day!
This ticket may in fact be invalid as per the resolution of
MC-212666.Well, it already has priority for a long time, so we'll see.
[~kuoxer], sounds events append, like tags, and like tags, they have a "replace" field. You simply need to provide that for your issue. This issue is about how the pitch and volume the event is played at by the game cannot be altered. Eg the lever on and off clicking playing at different pitches, the zombie ambient sounds getting (slightly) randomly pitched, etc.
Dhranios, ah, I see that you are referring to a different issue. My bad. Perhaps I'll create a new one.
Yours is not a bug, add "replace": true to the sound event, and its solved.
Affects snapshot 24w10a and release 1.20.4
Affects release 1.20.5
Requesting ownership if possible, due to the reporter being inactive and doesn't seem to be updating this report anymore.
Affects 1.21