Minecraft Bedrock Custom Sounds Guide (2026)

Add original sound events, random audio variations, automatic event replacements, and reliable command tests without losing track of file paths or identifiers.

Current Resource Pack workflowThis guide was checked against the stable Minecraft Creator custom sound documentation in July 2026. It uses sound_definitions.json, OGG audio, and command-first testing.

The short answer

Put custom audio inside the Resource Pack sounds/ folder and register a sound event in sounds/sound_definitions.json. The event name is what commands, entities, blocks, scripts, or other game systems call. Test the event with /playsound before wiring it into automatic gameplay.

Use lowercase names and a namespace such as icedfox:ruby_chime. Keep the event key separate from the physical file path: the key is a stable public identifier, while the definition can point to one or many audio files.

Prepare the audio correctly

  • Export to OGG for a practical balance of compatibility and file size.
  • Use lowercase file names with underscores and no spaces.
  • Trim long silence from the beginning and end.
  • Avoid extreme loudness; compare against vanilla sounds in the same category.
  • Use mono for localized effects when stereo positioning is not required.
  • Only distribute audio you created or have permission to use.

For this guide, export two short variations named ruby_chime_1.ogg and ruby_chime_2.ogg.

Create the Resource Pack structure

Resource Pack structure
RubySounds_RP/
  manifest.json
  sounds.json
  sounds/
    sound_definitions.json
    icedfox/
      ruby_chime_1.ogg
      ruby_chime_2.ogg

The audio path in JSON begins inside the Resource Pack and omits the extension. Both sounds/icedfox/ruby_chime_1 and the actual file location must agree exactly.

Step 1: register a custom sound event

Create sounds/sound_definitions.json. One event can choose randomly from several audio files, which prevents repeated effects from sounding identical.

sounds/sound_definitions.json
{
  "format_version": "1.20.20",
  "sound_definitions": {
    "icedfox:ruby_chime": {
      "category": "player",
      "sounds": [
        {
          "name": "sounds/icedfox/ruby_chime_1",
          "volume": 0.8,
          "pitch": 1.0,
          "weight": 2
        },
        {
          "name": "sounds/icedfox/ruby_chime_2",
          "volume": 0.8,
          "pitch": 1.05,
          "weight": 1
        }
      ]
    }
  }
}

The first variation has twice the selection weight of the second. The event key icedfox:ruby_chime is independent of the two file names, so you can replace or expand the variations later without changing every caller.

Start with a plain string entry if neededIf an object with volume, pitch, and weight does not play, temporarily reduce the sounds array to "sounds/icedfox/ruby_chime_1". Once the path works, add controls back one at a time.

Step 2: test with /playsound

Activate the Resource Pack in a disposable world with cheats enabled, then run:

Chat command
/playsound icedfox:ruby_chime @s ~ ~ ~ 1 1

If the command recognizes and plays the event, the audio file, definition, and Resource Pack are connected. Repeat the command to hear whether both weighted variations can occur. Only then should you connect the event to a mob, item, block, animation, or script.

Step 3: connect sounds to gameplay

There are two common paths:

  • Use sounds.json when mapping sounds to supported client sound events, such as entity or block interactions.
  • Call the custom event from commands, animation timelines, entity event responses, or Script API when you control the exact trigger.

For a supported vanilla event override, a root-level sounds.json can map that event to a registered sound definition. This example changes the chest-open event:

sounds.json
{
  "individual_event_sounds": {
    "events": {
      "chest.open": {
        "pitch": [0.95, 1.05],
        "sound": "icedfox:ruby_chime",
        "volume": 0.8
      }
    }
  }
}

This deliberately affects a known event for testing. A production add-on should avoid replacing broad vanilla events unless that global change is part of the design.

Replace a sound or add a new event?

Replace an existing file

Mirror the vanilla Resource Pack folder and base file name. This is useful for a dedicated sound pack, but it can conflict with other packs replacing the same vanilla asset.

Add a namespaced event

Register a new key in sound_definitions.json and call it from your content. This is usually safer for an add-on because it does not silently change unrelated vanilla behavior.

Download and inspect the official vanilla Resource Pack when you need the exact name and folder structure of a sound you intend to replace.

Design audio that works in play

  • Give frequent actions several short variations.
  • Reserve loud or long sounds for rare, meaningful events.
  • Use categories that respect the player's relevant volume controls.
  • Test overlapping sounds during combat and multiplayer.
  • Check distance falloff instead of testing only beside the source.
  • Compress distribution files without introducing audible artifacts.

A sound that is impressive once can become exhausting after fifty item uses. The correct test is not just whether it plays, but whether it still communicates clearly during real gameplay.

Custom sound test checklist

  1. Activate only the Resource Pack being edited.
  2. Test the namespaced event with /playsound.
  3. Test every variation in the definition.
  4. Walk away from the source and check distance behavior.
  5. Change music, blocks, players, and master volume settings.
  6. Trigger the real gameplay event repeatedly.
  7. Test with two players to confirm local versus global playback.
  8. Import the packaged add-on into a clean profile and retest.

Why a custom Bedrock sound does not play

The command cannot find the sound

Check the event key in sound_definitions.json, file placement under sounds/, valid JSON, and active Resource Pack. Remove duplicate imported pack versions.

The event exists but is silent

Verify the audio file opens outside Minecraft, the path omits the extension, volume is not zero, and the relevant in-game sound category is audible.

Only one variation plays

Confirm every path is unique and valid, then temporarily give each variation equal weight. A small random sample can also repeat the same valid file several times.

The sound plays everywhere

Review how the event is triggered and which players are targeted. A command or script targeting all players behaves differently from an event emitted at one entity or position.

The new pack still plays old audio

Increase the Resource Pack version, close and reopen the world, remove duplicate imports, and test in a fresh world. Pack caching can preserve a file you already replaced.

Frequently asked questions

Does the JSON path include .ogg?

No. The name normally points to the Resource Pack path without the audio file extension.

Can one event choose random sounds?

Yes. Add several entries to the event's sounds array. Optional weights let some variations occur more often than others.

Can Script API play these sounds?

Yes. Register the sound in the Resource Pack first, then use the appropriate stable Script API playback method for your target and version. Keep a command test so audio registration and script logic can be debugged separately.

Official sources checked