Replacing a Vanilla Sound Without Breaking the Rest

If you simply want to replace an existing audio clip with your own recording of the same length and style, you do not need to touch a single JSON file. When the game loads a sound event, it looks up the file path defined in the vanilla sound definitions and searches the active resource packs from top to bottom. If your resource pack contains an audio file at the exact same folder path with the exact same name, Bedrock will load your file instead of the default one.

For example, the vanilla sound event for glass breaking points to three files: `sounds/random/glass1`, `sounds/random/glass2`, and `sounds/random/glass3`. To replace just the first variation, export your custom audio as an Ogg Vorbis (`.ogg`) file, name it `glass1.ogg`, and place it inside `RP/sounds/random/` in your resource pack. The other two variations (`glass2` and `glass3`) will continue to load from the base game.

This is the safest method available. Because you are not shipping a `sound_definitions.json` file, there is zero risk of accidentally wiping out new sounds added in future Minecraft updates, and your pack will play nicely with other resource packs that modify different sounds.

Direct file replacement falls short when you want to change the number of variations a sound event has, alter its category, adjust its base volume or pitch, or stop the vanilla files from playing at all when a vanilla event has three files and you only made one replacement. In these cases, you must override the sound event itself inside `RP/sounds/sound_definitions.json`.

The golden rule here is to only include the specific sound event keys you are changing. Never copy the entire vanilla `sound_definitions.json` into your pack. When Bedrock loads resource packs, it merges the keys inside `sound_definitions` across all active packs. Any sound event key you leave out of your file will safely fall back to the vanilla definition (or the next pack down in the stack).

However, once you declare a sound event key in your file, your definition for that specific key replaces the vanilla one unless you tell it otherwise. To replace all three vanilla glass breaking sounds with a single custom audio file, you must set the `replace` property to `true` inside your event definition.

{
  "format_version": "1.14.0",
  "sound_definitions": {
    "random.glass": {
      "__use_legacy_max_distance": "true",
      "category": "block",
      "replace": true,
      "sounds": [
        {
          "name": "sounds/custom/shatter_heavy",
          "volume": 0.9,
          "pitch": 1.0
        }
      ]
    }
  }
}

By default, when two packs define the same sound event in `sound_definitions.json`, Bedrock attempts to merge their `sounds` arrays together rather than overwriting them. If you define `random.glass` with your one custom sound and omit `"replace": true`, the game will add your custom sound to the pool alongside `glass1`, `glass2`, and `glass3`. The player will hear your custom sound only 25% of the time.

Setting `"replace": true` tells the engine to discard the `sounds` array from all lower-priority packs (including the base game) for that specific event key, ensuring only the files listed in your array are used. Conversely, if your goal is to *add* a fourth variation to the vanilla glass break without losing the original three, simply omit `"replace": true` (or set it to `false`) and list only your new file in the `sounds` array.

When overriding an existing vanilla sound event in `sound_definitions.json`, always check how the vanilla resource pack defines that event first. Many older vanilla sound events include the field `"__use_legacy_max_distance": "true"` or explicit `max_distance` values.

If you override a vanilla event and leave out `"__use_legacy_max_distance": "true"` when the original had it, the attenuation (how quickly the sound fades out as the player walks away) may change drastically, making the sound audible from much farther away or cutting it off too soon. Copy the category and distance flags from the vanilla entry for that specific event so your replacement behaves consistently with the rest of the game.

You may also notice a file named `RP/sounds.json` in the vanilla resource pack. While `sound_definitions.json` maps a sound event string (like `random.glass`) to actual `.ogg` file paths, `sounds.json` maps game triggers—such as entity events, block interactions, and step sounds—to those sound event strings.

Unless you want to change which sound event a specific block or entity calls (for example, making dirt blocks use a custom sound event while grass blocks keep using the old shared one), do not include `RP/sounds.json` in your pack. Modifying `RP/sounds.json` is much more prone to conflicts between add-ons because overriding a block or entity sound block there requires redefining that entire block or entity entry. Stick to direct `.ogg` replacement or `sound_definitions.json` whenever possible.

Applies to all modern Bedrock versions (format_version 1.14.0 for sound_definitions.json is supported since 1.14 and remains standard in 1.20 and 1.21+). No experimental toggles are required.

Read out of the game itself, so the ids match the version you are building for.