Sound Definitions Reference (sound_definitions.json)

In a Bedrock resource pack, sound definitions live at the exact path RP/sounds/sound_definitions.json. Unlike entity or block files, this is a single master registry for the entire resource pack rather than one file per sound. If multiple resource packs are active in a world, the game merges their sound_definitions.json files from bottom to top of the pack stack, overwriting matching sound event keys.

Modern packs use format_version "1.14.0" or "1.20.20" at the root level. Inside the root object, all sound events sit inside the "sound_definitions" dictionary. Older vanilla files sometimes omit the "sound_definitions" wrapper and place sound event keys directly at the root alongside the format version, but you should always use the wrapper in new packs to avoid parser conflicts.

Actual audio files sit inside the RP/sounds/ folder or its subfolders. Bedrock supports Ogg Vorbis (.ogg) and uncompressed WAV (.wav) files, with Mono .ogg strongly preferred for 3D positional audio. When referencing these files in JSON, you always omit the file extension.

{
  "format_version": "1.14.0",
  "sound_definitions": {
    "mob.custom_goblin.idle": {
      "category": "neutral",
      "max_distance": 16.0,
      "min_distance": 2.0,
      "sounds": [
        "sounds/mob/goblin/idle1",
        {
          "name": "sounds/mob/goblin/idle2",
          "volume": 0.85,
          "pitch": 1.1,
          "weight": 2,
          "stream": false,
          "is3D": true
        }
      ]
    }
  }
}

Each key inside "sound_definitions" is a sound event identifier, such as "mob.custom_goblin.idle" or "custom.magic.spell_cast". These identifiers do not take a namespace colon; instead, they use dot-separated paths by convention. This exact string is what you pass to the /playsound command, animation sound effects, or RP/sounds.json.

The properties directly inside a sound event object apply to every audio file listed inside that event's "sounds" array. They control how the sound is categorized in the player's audio settings and how far away the sound can be heard in the 3D world.

The "sounds" array holds the actual paths to your audio files. If you do not need to tweak the playback settings for a specific file, you can write the entry as a plain string, such as "sounds/mob/goblin/idle1". The path is always relative to the root of the resource pack, not the RP/sounds/ folder.

When you need fine control over volume, pitch, selection chance, or memory handling for an individual audio variation, you write the entry as an object instead of a string. When multiple entries are listed in the "sounds" array, the engine picks one at random each time the event is triggered, weighted by the "weight" property.

The "category" field links your sound event to the sliders in the player's Audio Settings screen and controls certain engine behaviours like default 3D panning and voice limits. Choosing the right category ensures players can turn down ambient noise or hostile mobs without muting your custom items.

Registering an event in RP/sounds/sound_definitions.json only creates the identifier and configures its files; it does not tell the game when to play it. To trigger your sound automatically on entity actions (such as step, hurt, or death) or block interactions, you reference the identifier inside RP/sounds.json, which sits in the root of your resource pack.

You can also trigger any defined sound event directly from a client entity file (by mapping a short name in the entity's "sound_effects" description block and calling it in an animation or animation controller), from a behaviour pack animation, via the Script API using Player.playSound() or Dimension.playSound(), or directly in-game with the /playsound command.

{
  "format_version": "1.10.0",
  "minecraft:client_entity": {
    "description": {
      "identifier": "my_pack:custom_goblin",
      "sound_effects": {
        "laugh": "mob.custom_goblin.idle"
      }
    }
  }
}

Applies to all modern Bedrock versions (format_version 1.14.0 and 1.20.20). No experimental toggles are required.

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