DEV Community: Alex Creatune

How to Fit a Christmas Song into a 30-Second Video: Measure, Then Cut

Alex Creatune — Wed, 11 Nov 2026 03:18:19 +0000

A 30-second greeting video needs a 30-second song, and a Christmas track rarely arrives at that length. The sample songs on Creatune's public Christmas page run from 1:39 to 3:44. This guide shows how to measure a song file with Python, choose the 30 seconds you want, cut them, and confirm the result lands inside a tolerance you set.

I'm Alex from the Creatune team. On November 11, 2026, I checked our public Christmas song generator and audio cutter pages, then ran every script below on a synthetic 74-second stand-in file, so you can reproduce the numbers without a song of your own. The measurements describe that stand-in file and the cutter's output.

What you need

The video length in seconds (30.0 here)
A song file: a download from the generator, or any WAV or MP3 you have the rights to use
Python 3 (the standard library is enough)
Optional: ffprobe, for formats that Python's wave module cannot read

Decide the tolerance before you start. At 30 frames per second one frame lasts 0.0333 s, so a tolerance of ±0.1 s is three frames. That is a number you can write in a delivery note and check with a script.

Step 1: Describe the song and download it

Open the Christmas song generator. On the Simple tab, type your idea into the prompt box, which accepts up to 500 characters. The page also offers an Instrumental Only checkbox and style chips such as Christmas Pop, Sleigh Bells, Cozy, Acoustic, Choir, Jazz, and Kids. This prompt is a good starting point for a neighbor greeting:

A warm Christmas greeting song for my neighbors, acoustic guitar, sleigh bells, one short chorus, female vocal

Whatever the prompt says about length, the downloaded file is what counts. Keep the download as it is and use the steps below on it. Plan on trimming: the samples on the page last 3:44, 1:39, 2:42, and 2:53.

Step 2: Measure the source

To follow along without a song, this script writes a 74-second stereo WAV. It plays a four-note pattern (C, E, G, E) at 96 BPM, so one beat lasts 0.625 s and one four-beat bar lasts 2.5 s:

import math
import struct
import wave

RATE = 44100
SECONDS = 74
NOTES = [261.63, 329.63, 392.00, 329.63]  # C4 E4 G4 E4, one note per beat at 96 BPM
BEAT = 60 / 96

frames = bytearray()
for n in range(RATE * SECONDS):
    t = n / RATE
    freq = NOTES[int(t / BEAT) % len(NOTES)]
    value = 0.25 * math.sin(2 * math.pi * freq * t)
    sample = struct.pack("<h", round(value * 32767))
    frames.extend(sample * 2)  # same sample in left and right

with wave.open("standin-74s.wav", "wb") as audio:
    audio.setnchannels(2)
    audio.setsampwidth(2)
    audio.setframerate(RATE)
    audio.writeframes(frames)

Now read the length from the file itself. For an uncompressed WAV, duration is frames divided by sample rate:

import wave

for name in ("standin-74s.wav", "cut-30s.wav"):
    with wave.open(name, "rb") as audio:
        rate = audio.getframerate()
        frames = audio.getnframes()
        print(f"{name}: rate={rate} channels={audio.getnchannels()} "
              f"frames={frames} seconds={frames / rate:.4f}")

Run it once now. The second file does not exist yet, so Python stops with a FileNotFoundError after printing the first line:

standin-74s.wav: rate=44100 channels=2 frames=3263400 seconds=74.0000

The source is 74.0 s, so 44.0 s has to go. Because this track has a steady tempo, cut on bar lines so the music starts and ends on a downbeat. Bar 5 begins at 4 × 2.5 = 10.0 s, and 30 s later is 40.0 s, which is the start of bar 17. For your own song, replace 96 BPM with its tempo: seconds per bar = 4 × 60 / BPM.

Step 3: Cut the section

Open the audio cutter and choose your file with Choose audio. The page lists MP3, WAV, M4A, FLAC, and OGG, keeps local audio on your device, and states a limit of 50 MB per file and five minutes at the time of my check.

After the file loads, the page shows its name and length (74.0 s here) plus Start (s) and End (s) fields. Enter 10 and 40. The label at the lower left changes to Total: 30.0 s. Open the format menu, which offers MP3, WAV, and FLAC, choose WAV so the file can be measured frame by frame, and select Download.

The browser suggested standin-74s-audio-cutter.wav. Save a copy as cut-30s.wav next to the source so the measuring script finds it.

Step 4: Verify the cut

Run the same measuring script again:

standin-74s.wav: rate=44100 channels=2 frames=3263400 seconds=74.0000
cut-30s.wav: rate=44100 channels=2 frames=1323000 seconds=30.0000

File	Sample rate	Channels	Frames	Duration
standin-74s.wav	44,100 Hz	2	3,263,400	74.0000 s
cut-30s.wav	44,100 Hz	2	1,323,000	30.0000 s

1,323,000 frames ÷ 44,100 Hz is exactly 30 s, so the difference from the target is 0.0000 s, inside the ±0.1 s tolerance.

If your download is an MP3 or another format wave cannot open, ask ffprobe for the duration instead:

ffprobe -v error -show_entries stream=codec_name,sample_rate,channels:format=duration -of default=nw=1 cut-30s.mp3

Finish with a short acceptance record you can keep next to the project:

Video length: 30.0 s
Tolerance: ±0.1 s
Source: standin-74s.wav, 74.0000 s
Cut: 10.0 s to 40.0 s (bar 5 to bar 17 at 96 BPM)
Delivered: cut-30s.wav, 1,323,000 frames at 44,100 Hz = 30.0000 s
Result: within tolerance

Questions that come up

What if the song is shorter than 30 seconds? Nothing needs cutting. Decide whether the video can wait for a longer version of the track, and measure again after any change.

Should the cut end on the last frame of the video? The cut fixes the length; a fade-out is a separate edit. Add the fade in your video editor so the music does not stop in the middle of a note. A fade changes loudness over time, not the file's duration.

The start sounds abrupt. Can I move it? Yes. Shift both Start and End by the same amount so the total stays at 30.0 s, and run the measuring script again.

My video is 24 fps, not 30. Does the tolerance change? One frame is 0.0417 s, so ±0.1 s is about two frames. Tighten the tolerance if your delivery spec asks for it.

What Does 24-bit PCM Mean? Check Sample Width After a WAV Export

Alex Creatune — Sun, 08 Nov 2026 14:00:57 +0000

A WAV delivery request can specify 24-bit PCM. To check that requirement, read the sample width of the delivered file. The filename and the waveform display provide other information, while sample width answers how many bytes store each sample.

I'm Alex from the Creatune team. On November 8, 2026, I created a one-second 24-bit PCM fixture, converted it through our public English audio converter, and inspected the downloaded WAV. The measurements below cover file metadata. I did not perform a listening comparison.

Put bit depth, sample rate, and channels in separate fields

For ordinary integer PCM, bit depth describes the number of bits used for each channel's sample. A 24-bit sample occupies three bytes. A 16-bit sample occupies two. Their representable integer grids contain 2^24 and 2^16 values respectively.

Sample rate describes the number of frames per second. Channel count describes how many samples occur in each frame. For an uncompressed PCM payload, the basic relationship is

payload_bytes = frames * channels * bytes_per_sample
seconds = frames / sample_rate

A WAV file also contains a header and may contain additional chunks, so its total byte size can exceed the audio payload. Treat the delivered file's encoding, sample rate, channel count, and duration as separate acceptance fields.

Create a source with known properties

This Python script writes a mono, 48 kHz, 24-bit integer PCM WAV. It uses a short synthetic tone so the example can be reproduced without recording or licensing an external track.

import math
import wave

rate = 48000
samples = bytearray()
for frame in range(rate):
    value = round(0.2 * 8388607 * math.sin(2 * math.pi * 440 * frame / rate))
    samples.extend(value.to_bytes(3, "little", signed=True))

with wave.open("mono24-48000-1s.wav", "wb") as audio:
    audio.setnchannels(1)
    audio.setsampwidth(3)
    audio.setframerate(rate)
    audio.writeframes(samples)

The positive full-scale integer for signed 24-bit PCM is 8,388,607. The 0.2 multiplier keeps this fixture's amplitude comfortably inside its numeric range.

Convert the fixture and retain both files

Open the English Creatune audio converter and choose the fixture with Choose audio. The page displayed the filename and a rounded duration of 1.0 s. In this session, the initial output selection was MP3. Audio converter

Open Output format, select WAV, and choose Download. Keep the source file and save a separate copy of the download as converted.wav. The browser suggested mono24-48000-1s-audio-converter.wav during this test.

The visible controls in this workflow select the output format. They do not expose a separate bit-depth selector. The export therefore needs a file-level check against any 24-bit delivery requirement.

Read the downloaded metadata

Run this script in the directory containing the two files

import wave

for name in ("mono24-48000-1s.wav", "converted.wav"):
    with wave.open(name, "rb") as audio:
        width = audio.getsampwidth()
        rate = audio.getframerate()
        frames = audio.getnframes()
        print(
            name,
            "width_bytes=", width,
            "bits=", width * 8,
            "rate=", rate,
            "channels=", audio.getnchannels(),
            "frames=", frames,
            "seconds=", frames / rate,
        )

Python's wave reader supports the uncompressed PCM files used here. A float or compressed WAV may need a reader that supports its encoding. If the reader rejects the file, inspect that encoding before treating its width as an integer-PCM bit depth.

These are the values measured in this run

Field	Source	Downloaded WAV
Bytes per sample	3	2
Integer PCM bit depth	24	16
Sample rate	48,000 Hz	44,100 Hz
Channels	1	2
Frames	48,000	44,099
Duration	1.0 s	0.9999773242630385 s

The downloaded file used 16-bit PCM, so it did not meet a requirement to retain 24-bit PCM. Its sample rate and channel count also changed. At 44.1 kHz, 44,100 frames would make exactly one second. This output had one fewer frame, about 22.7 microseconds shorter, while the tool's rounded display still showed 1.0 s.

Those observations apply to this fixture and this export. The measurements establish the stored format and duration. They leave listening quality, effective recording resolution, and the treatment of other inputs for separate checks.

Turn the requirement into a reproducible decision

Write an acceptance record before delivering the converted file

Required encoding: integer PCM
Required sample width: 3 bytes / 24 bits
Required sample rate: 48000 Hz
Required channels: 1
Duration tolerance: define it with the recipient
Observed output: 2 bytes / 16 bits, 44100 Hz, 2 channels
Decision for this requirement: choose an export workflow with the required controls

Increasing the sample width of an already quantized file can provide a larger storage representation, while the earlier quantization has already limited the stored values. Keep the original recording when later processing or delivery depends on that precision.

Our earlier WAV handoff checklist helps turn these fields into an explicit agreement with the next tool or collaborator. WAV delivery requirements

For a separate amplitude check after processing, our reproducible gain test shows how to measure sample peaks and record their units. Measuring a gain change with sample peaks

How to Check Audio Duration After a Speed Change: Why 0.8 Takes 25% Longer

Alex Creatune — Fri, 06 Nov 2026 03:57:52 +0000

A practice track is eight seconds long. You set its speed to 0.8×. Should the result last 9.6 seconds or 10 seconds?

It should last 10 seconds. The speed is 20% lower, but the duration is 25% longer. If you are fitting a rehearsal clip into a fixed slot, confusing those percentages gives you the wrong endpoint before you even export.

I’m Alex from the Creatune team. I tested the duration calculation below with a synthetic WAV in our public speed changer on November 4, 2026. The measurements cover exported file duration and format metadata; they do not establish listening quality or pitch preservation.

Start with the inverse relationship

For a constant speed multiplier s, with no trimming or added padding:

output_duration = input_duration / s
speed_multiplier = input_duration / target_duration

A multiplier describes how quickly you move through the original timeline. At 0.8×, one second of source material needs 1 / 0.8 = 1.25 seconds to play.

For an eight-second source:

Speed	Calculation	Expected duration	Change from the source
0.8×	8 / 0.8	10 seconds	25% longer
1×	8 / 1	8 seconds	Unchanged
1.25×	8 / 1.25	6.4 seconds	20% shorter

The percentage change in duration is (1 / s - 1) * 100, not (1 - s) * 100.

This also works backwards. To stretch eight seconds to ten seconds, request 8 / 10 = 0.8×. If the interface cannot represent your exact multiplier, treat the chosen value as an approximation and measure the export.

Make a source whose duration you know

Use a short WAV you own, or generate the same eight-second fixture with Python’s standard library. No microphone or third-party audio is needed.

import math
import struct
import wave

rate = 44100
frames = rate * 8
samples = [
    round(0.2 * 32767 * math.sin(2 * math.pi * 440 * n / rate))
    for n in range(frames)
]

with wave.open("tone440-8seconds.wav", "wb") as out:
    out.setnchannels(1)
    out.setsampwidth(2)
    out.setframerate(rate)
    out.writeframes(struct.pack("<" + "h" * frames, *samples))

This creates 352,800 frames of mono, 16-bit PCM at 44,100 Hz. The 440 Hz tone supplies a simple signal for the file; counting its frames supplies the exact input duration. A steady tone does not test how a music processor handles drum attacks, voices, or complex mixes.

Export two settings from the same original

Open the English Creatune music speed changer. In the public interface I checked, the Speed control runs from 0.5× to 2× in steps of 0.05, and the output choices are MP3, WAV, and FLAC.

Choose tone440-8seconds.wav as the input.
Set Speed to 0.8×. Confirm that the input still reads 8.0 s and Total reads 10.0 s.
Set the output format to WAV, then select Download. Save or rename this export as speed-080.wav.

Keep the original file loaded. Change Speed to 1.25×. The displayed Total becomes 6.4 s.
Download another WAV and save it as speed-125.wav.

Use separate filenames so that the second download does not replace the first. Do not load speed-080.wav as the second input: that would test a second processing pass on the ten-second export, rather than a different setting on the original eight seconds.

The page currently states a 50 MB file limit and up to five minutes on desktop, or 2.5 minutes on small screens. This fixture is comfortably inside those limits.

Count frames in the downloaded files

A rounded Total label is useful for setting up the operation. The exported file is the thing to measure before placing it on a timeline.

import wave

for name in (
    "tone440-8seconds.wav",
    "speed-080.wav",
    "speed-125.wav",
):
    with wave.open(name, "rb") as audio:
        frames = audio.getnframes()
        rate = audio.getframerate()
        print(
            name,
            "frames=", frames,
            "rate=", rate,
            "channels=", audio.getnchannels(),
            "bytes_per_sample=", audio.getsampwidth(),
            "seconds=", frames / rate,
        )

Here are the actual file measurements from this test:

File	Frames	Sample rate	Channels	Bytes per sample	Duration
Original	352,800	44,100 Hz	1	2	8.0 s
0.8× export	441,000	44,100 Hz	2	2	10.0 s
1.25× export	282,240	44,100 Hz	2	2	6.4 s

Both measured durations match the inverse-speed calculation exactly for this fixture. The exports also have two channels, while the source has one. That is why raw file size is a poor shortcut for checking duration here: channel count changed too.

A frame contains one sample for each channel at one instant. Divide frames by sample rate to get seconds. Do not divide that result by the number of channels.

Diagnose a mismatch without guessing

If a downloaded clip is not the length you expected, check these in order:

Input identity: was the original file still loaded, or did you accidentally process a previous export?
Multiplier: did you enter a speed factor such as 0.8, or a percentage such as 20?
File identity: are you inspecting the newest export with the intended setting?
Measurement: use decoded frames and sample rate, rather than file bytes or a rounded player label. The Python example above is for PCM WAV; an MP3 needs an appropriate decoder.
Extra operations: trimming, padding, or a second processing pass changes the calculation. Record those separately before attributing a mismatch to speed.

Matching duration is only one acceptance check. For a rehearsal track, also listen to the beginning, transitions, and ending at a comfortable volume, and judge whether the instruments and words remain useful for your purpose. I did not perform that listening comparison in this test.

Related checks

If your next question is whether the pace itself matches the intended beat, our earlier reproducible click-track tempo check explains how to establish a known BPM reference.

If your workflow joins files with different sample rates, checking duration when joining 44.1 kHz and 48 kHz audio shows why you must read each file’s sample rate before converting frame counts to seconds.

A Fade-Out Is Not Yet a Crossfade: Test the Timeline Before Shipping Audio

Alex Creatune — Tue, 03 Nov 2026 06:42:56 +0000

You soften the end of the first clip, export a join, and expect the second clip to start earlier. It may not. A fade changes amplitude over time; a crossfade also overlaps neighboring clips. Those are separate decisions when the output must stay aligned with a video cue.

I'm Alex from the Creatune team. I tested this distinction in our public Audio Joiner with two synthetic WAV files on November 1, 2026. This is a file-duration experiment, not a listening test or a claim about which transition sounds better.

Make two clips whose lengths are unambiguous

Use Python's standard library to create two two-second, mono, 16-bit WAV files at 44.1 kHz. Different tones make the sources distinguishable if you later inspect the transition, but the test below measures duration only.

import math, struct, wave

rate = 44100
for hz in (440, 880):
    samples = [round(0.25 * 32767 * math.sin(2 * math.pi * hz * n / rate))
               for n in range(rate * 2)]
    with wave.open(f"tone{hz}.wav", "wb") as w:
        w.setparams((1, 2, rate, 0, "NONE", "not compressed"))
        w.writeframes(struct.pack("<" + "h" * len(samples), *samples))

Keep both source intervals at Start 0 and End 2. Leave Trim silence at joins unchecked so silence removal cannot become a second cause of a duration change. Use WAV output to make the sample-frame check straightforward.

Test A: fade out only

Open Creatune Audio Joiner, choose the two files, and confirm the order: 440 Hz first, 880 Hz second. The public page says local audio stays on the device.

Enable Fade out on the first clip and set its duration to 1 second. Leave the second clip's Fade in off. In this test the join label remained Direct join, and the total remained 0:04.0.

Download the WAV and save it as fade-out-only.wav. A fading tail does not by itself move the next clip to an earlier time in this configuration.

Test B: enable the matching fade-in

Keep every other setting unchanged. Enable Fade in on the second clip and set it to 1 second. The join now displayed Crossfade · 1.0 s, and the total became 0:03.0.

Download again, this time as crossfade-both.wav. For this equal-duration case:

output duration = first clip + second clip - overlap
                = 2 + 2 - 1
                = 3 seconds

There is one overlap region, so subtract it once. Do not subtract one second twice merely because two fade controls are enabled. This experiment does not establish how unequal fade lengths are resolved; read the actual join label and measure a fresh export for that case.

Verify the files, not just the rounded UI

import wave

for name in ("fade-out-only.wav", "crossfade-both.wav"):
    with wave.open(name, "rb") as w:
        frames, rate = w.getnframes(), w.getframerate()
        print(name, "frames=", frames, "rate=", rate,
              "channels=", w.getnchannels(), "seconds=", frames / rate)

The downloaded files measured:

Configuration	Sample frames	Rate	Channels	Duration
First clip fade-out only	176400	44100	2	4.0 s
First fade-out + second fade-in	132300	44100	2	3.0 s

Use frames / sample rate, not the total number of interleaved channel samples. The output happened to be stereo even though the inputs were mono; multiplying by channel count would incorrectly double the duration.

Turn the distinction into a delivery check

If a second spoken cue must start at exactly two seconds, a one-second overlap changes that schedule. If the intention is a musical handover, that overlap may be useful. Choose the timing requirement first, then the fade settings.

Before delivery, record the source intervals, each enabled fade, the displayed overlap, and the measured export duration. Then listen for lost consonants, a masked attack, or an unwanted dip at the boundary. Duration alone cannot establish smoothness, and tones are not a substitute for checking speech or music in context.

For a repeatable handoff, our earlier guide shows how to write a clip manifest you can rebuild. If the timing is right but the boundary still sounds rough, the sample-boundary check for an exact audio cut explains a different failure mode. Both are team-authored follow-up tutorials, not independent product reviews.

Joining Audio Is Not Mixing: Verify the Difference with Two Tones

Alex Creatune — Sat, 31 Oct 2026 03:51:41 +0000

Putting a voice clip and a backing track into an audio joiner does not automatically place the voice over the music. A direct join places one clip after another. A mix combines signals that occupy the same time interval.

I’m Alex from the Creatune team. I checked this distinction with two synthetic WAV files and an actual export from our public Audio Joiner. The observations below are file measurements, not listening impressions.

Write the expected timeline before choosing a tool

For two clips that each last two seconds, a direct join should produce roughly four seconds. Starting both clips together in a mix would instead produce roughly two seconds, assuming neither is extended. A crossfade overlaps only part of a transition; it is not the same as placing two complete tracks together.

In sample terms, concatenation is A followed by B. Mixing is gain_A * A[n] + gain_B * B[n] at each shared time position, with alignment and headroom decisions. A louder sum can clip even when neither original clips, so simply adding arrays is not a complete mixing workflow.

Make a test whose parts are easy to identify

Use Python’s standard library to create a 440 Hz tone and an 880 Hz tone, both two seconds long at 44,100 Hz. These are our own test signals, not music taken from another artist.

import math, struct, wave

for name, hz in (("first-440.wav", 440), ("second-880.wav", 880)):
    with wave.open(name, "wb") as w:
        w.setparams((1, 2, 44100, 0, "NONE", "not compressed"))
        w.writeframes(b"".join(
            struct.pack("<h", round(8192 * math.sin(2 * math.pi * hz * i / 44100)))
            for i in range(88200)
        ))

On Creatune Audio Joiner, choose the two files and keep 440 Hz first. Leave their start and end values at the full two seconds. Keep fades and “Trim silence at joins” off, and confirm the transition says “Direct join.” Choose WAV as the output format.

The public page shows local files remain on the device. The screenshots use the signed-out interface. I clicked Download and measured the resulting WAV; no music generation was involved.

Inspect duration and two interior windows

The exported file contained 176,400 frames at 44,100 Hz: exactly 4.000000 seconds, with two channels. The input files were mono, so this export changed the channel count. That observation belongs to this test; it is not a promise about every source or browser.

To distinguish sequential tones from simultaneous tones, inspect windows away from the join: 0.5–1.0 seconds and 2.5–3.0 seconds. The following standard-library check measures the amplitudes at the two known frequencies in the first output channel. It is a narrow test for these fixtures, not a general music pitch detector.

import array, math, sys, wave
from pathlib import Path
path = Path(sys.argv[1]) if len(sys.argv) > 1 else Path('joined.wav')
with wave.open(str(path), 'rb') as w:
    assert w.getsampwidth() == 2, 'This check expects 16-bit PCM WAV'
    rate, channels, frames = w.getframerate(), w.getnchannels(), w.getnframes()
    samples = array.array('h', w.readframes(frames))
if sys.byteorder != 'little':
    samples.byteswap()
x = [v / 32768 for v in samples[::channels]]
print(f'{rate} Hz; {channels} channels; {frames} frames; {frames/rate:.6f} seconds')
for start in (0.5, 2.5):
    window = x[round(start * rate):round((start + 0.5) * rate)]
    def amplitude(hz):
        angle = 2 * math.pi * hz / rate
        real = math.fsum(v * math.cos(angle * i) for i, v in enumerate(window))
        imag = math.fsum(v * math.sin(angle * i) for i, v in enumerate(window))
        return 2 * math.hypot(real, imag) / len(window)
    print(f'{start:.1f}-{start+0.5:.1f}s: A440={amplitude(440):.6f}, A880={amplitude(880):.6f}')

Run it as python verify-join.py joined.wav, using your downloaded file’s name. My output was:

44100 Hz; 2 channels; 176400 frames; 4.000000 seconds
0.5-1.0s: A440=0.250000, A880=0.000001
2.5-3.0s: A440=0.000000, A880=0.250000

The first window contains the 440 Hz test tone; the second contains the 880 Hz tone. Small residual values are not a second musical layer. Together with the duration and direct-join setting, these measurements support sequential placement. They do not establish perceptual quality or guarantee sample-identical output.

Use the result to choose the next operation

A sequence of interview answers or a listening reel needs joining. A voice over background music needs a mixer or multitrack editor with time alignment and independent levels. If the goal is a short transition, a crossfade may be appropriate, but check the new total duration and the overlap separately.

For a longer sequence, verify clip order with three identifiable tones before judging transitions. If your source files use different sample rates, check duration using the output frame count; that catches a different class of timeline error.

Why a Healthy Stereo Waveform Can Disappear in Mono

Alex Creatune — Fri, 30 Oct 2026 03:40:15 +0000

A waveform can look substantial, and both channels can contain valid samples, while a mono mix of the same file is almost silent. Before blaming the audio converter, check how the left and right channels relate to each other.

I’m Alex, a member of the Creatune team. This is a reproducible numerical test with an original synthetic signal, not a listening comparison or a claim about every playback device.

Build a deliberately extreme control

For this control, the right channel is the exact negative of the left. This is a polarity inversion, not a time delay. For a sine wave it is also equivalent to a half-cycle phase difference; that equivalence should not be generalized to arbitrary music.

import math, struct, wave
frames = bytearray()
for i in range(96000):
    left = round(8000 * math.sin(2 * math.pi * 440 * i / 48000))
    frames.extend(struct.pack('<hh', left, -left))
with wave.open('antiphase.wav', 'wb') as w:
    w.setparams((2, 2, 48000, 0, 'NONE', 'not compressed'))
    w.writeframes(frames)

This creates two seconds of 48 kHz, 16-bit stereo audio. Each channel has a peak sample magnitude of 8000. A simple mono average is (left + right) / 2, which is zero for every frame of this input.

Do not use the control at high listening volume: numerical verification does not require playback.

Pass it through an explicit WAV conversion

Open the Creatune audio converter, choose the generated file, and wait for its waveform and two-second duration to appear. The public interface accepts local audio and offers MP3, WAV, and FLAC output.

Open Output format, select WAV, and download the result as antiphase-export.wav. The initial format in this run was MP3, so choosing WAV is a deliberate part of the test.

Measure channels before measuring their sum

import math, struct, wave
for path in ['antiphase.wav', 'antiphase-export.wav']:
    with wave.open(path, 'rb') as w:
        assert w.getnchannels() == 2 and w.getsampwidth() == 2
        n = w.getnframes()
        values = struct.unpack('<' + 'h' * n * 2, w.readframes(n))
        left, right = values[::2], values[1::2]
        mono = [(a + b) / 2 for a, b in zip(left, right)]
        rms = lambda a: math.sqrt(sum(x*x for x in a) / len(a))
        print(path, w.getframerate(), n,
              max(map(abs, left)), max(map(abs, right)),
              round(rms(left), 2), max(map(abs, mono)))

On October 30, 2026, the input measured 48000 Hz and 96000 frames. The downloaded WAV measured 44100 Hz and 88199 frames, with two 16-bit channels. Both output channel peaks were still 8000; left-channel RMS was 5656.71. The maximum absolute value of the mono average was 0 in both files.

The export therefore retained the exact cancellation relationship in this test. It did not retain the original sample rate or frame count. The waveform preview was not evidence of mono compatibility, and the silent mono average was not evidence that the stereo channels were empty.

Use the result to isolate a real delivery problem

For an affected music file, keep three separate checks: left alone, right alone, and the intended mono fold-down. Compare identical time ranges and avoid changing playback gain between checks. A weak mono result with strong individual channels is a reason to investigate stereo processing, duplicated tracks, polarity, and the actual downmix rule.

Do not automatically invert a channel in finished music. That may improve one source while damaging another. Our exact inverse control is intentionally unrealistic; partial cancellation in music varies with frequency and time, and a device may use a different mix than the simple average above.

For the amplitude side of the investigation, checking a gain change with sample peaks explains what a peak measurement can establish before a listening comparison. For a file that is correct except for a click at its edge, checking an exact cut for a rough boundary covers a different failure that a duration check alone misses. Both are earlier tutorials from our team.

How to Check Duration When Joining 44.1 kHz and 48 kHz Audio

Alex Creatune — Thu, 29 Oct 2026 05:28:32 +0000

Two clips can both last two seconds while containing different numbers of sample frames. A 44.1 kHz clip has 88,200 frames; a 48 kHz clip has 96,000. Adding those frame counts and dividing by just one of the input rates gives the wrong expected duration.

For a direct join with no trimming or overlap, calculate the duration of each input first, then add the durations. After export, read the output's own sample rate. Do not assume it matches every input.

I'm Alex from the Creatune team. On October 29, 2026, I joined two synthetic fixtures through the signed-out public interface and inspected the downloaded WAV. This is a file-level duration check, not a listening test or a claim about resampling quality.

Make the mismatch deliberate

This standard-library Python script makes two mono, 16-bit PCM WAV files. Different tone frequencies help keep the fixtures distinct, although the duration test below does not use pitch as evidence.

import math
import struct
import wave

for name, rate, frequency in [
    ("tone-44100.wav", 44100, 440),
    ("tone-48000.wav", 48000, 660),
]:
    samples = b"".join(
        struct.pack("<h", round(5000 * math.sin(2 * math.pi * frequency * i / rate)))
        for i in range(rate * 2)
    )
    with wave.open(name, "wb") as w:
        w.setparams((1, 2, rate, 0, "NONE", "not compressed"))
        w.writeframes(samples)

Each file lasts exactly two seconds. The expected total is therefore four seconds, not (88200 + 96000) / 44100 seconds.

Set up a direct join

Open Creatune Audio Joiner, choose the two files, and keep them in 44.1 kHz then 48 kHz order. Keep both Start values at 0 and both End values at 2. Leave fades disabled and confirm the transition says Direct join.

Leave Trim silence at joins unchecked. Choose WAV in Output format, then Download. Save the downloaded file as joined.wav for the script below. These controls matter because a trim or overlapping crossfade would change the expected duration independently of sample rate.

The interface showed a total of 0:04.0. That is useful feedback, but its rounded display cannot resolve a one-frame difference.

Measure seconds before comparing frames

Run this in the directory containing the three WAV files:

import wave


def info(name):
    with wave.open(name, "rb") as w:
        return w.getnframes(), w.getframerate(), w.getnchannels(), w.getsampwidth()


inputs = [info("tone-44100.wav"), info("tone-48000.wav")]
expected_seconds = sum(frames / rate for frames, rate, _, _ in inputs)
frames, rate, channels, width = info("joined.wav")
actual_seconds = frames / rate
error_in_output_frames = (actual_seconds - expected_seconds) * rate
print("output:", rate, channels, width, frames)
print(f"expected_seconds={expected_seconds:.9f}")
print(f"actual_seconds={actual_seconds:.9f}")
print(f"difference_in_output_frames={error_in_output_frames:.3f}")

The downloaded file in this run produced:

output: 44100 2 2 176399
expected_seconds=4.000000000
actual_seconds=3.999977324
difference_in_output_frames=-1.000

The export was 44.1 kHz stereo PCM16, one output frame shorter than the four-second calculation: about 22.7 microseconds. I record that difference rather than calling the result sample-exact. The two inputs were mono; the export having two channels does not establish that it contains spatial stereo information.

Decide what this test should catch

A duration near 4.17687 seconds would be consistent with the incorrect calculation of interpreting all 184,200 input frames at 44.1 kHz. That is a diagnostic clue, not proof of a particular implementation bug. A large discrepancy should first lead you to check trim ranges, fades, silence removal, and the actual downloaded file.

For short test fixtures, recording the error in output frames makes rounding visible. For a real delivery, set your tolerance before testing according to the receiving workflow; do not retroactively choose a limit just because an export passed it.

This check does not prove waveform identity, correct pitch, an inaudible seam, or high-quality resampling. Test those separately. A valid duration and a pleasant transition answer different questions.

Related checks

Our earlier note on why a WAV filename is not an audio delivery contract helps define the format requirements before accepting an export. If the result sounds faster or higher, separating a pitch shift from faster playback gives a separate diagnostic procedure. Both are English articles from our team.

How to Verify Clip Order in a Joined Audio File with Three Test Tones

Alex Creatune — Wed, 28 Oct 2026 08:54:47 +0000

A six-second export can have the right length and the wrong clip order. If you rearrange an intro, transition, and ending in an audio joiner, duration alone will not catch that mistake.

This small test gives each input a distinct signal, rearranges the inputs, and checks the downloaded file. I’m Alex from the Creatune team. I ran the public, signed-out workflow on October 28, 2026. These are synthetic fixture measurements, not a listening review or a claim about every possible input file.

Create three identifiable inputs

You need Python 3 and a browser. This standard-library script creates three two-second, mono, 16-bit PCM WAV files at 48 kHz:

import math, struct, wave

for name, hz in [("01-low.wav", 220),
                 ("02-mid.wav", 440),
                 ("03-high.wav", 880)]:
    with wave.open(name, "wb") as w:
        w.setparams((1, 2, 48000, 0, "NONE", "not compressed"))
        w.writeframes(b"".join(
            struct.pack("<h", int(8000 * math.sin(2 * math.pi * hz * i / 48000)))
            for i in range(96000)
        ))

Each file has the same duration and amplitude. Frequency is its identifying feature. Keep playback volume low if you choose to listen; listening is not required for the measurement below.

Rearrange the clips in Creatune

Open Creatune Audio Joiner, choose the three local files, and verify the displayed order before editing. The current page says local audio stays on the device and allows up to 12 tracks / 10 minutes, with a five-minute limit on small screens and 50 MB per file.

Use the Move up arrow on 03-high.wav twice so the final order is:

03-high.wav → 01-low.wav → 02-mid.wav
880 Hz      → 220 Hz     → 440 Hz

Leave each Start at 0 and End at 2. Leave Fade in and Fade out disabled, check that both joins say Direct join, and leave Trim silence at joins unchecked. These choices keep timing changes out of this particular test. Select WAV under Output format and download the result. Save it locally as reordered.wav.

The total shown in the interface is 0:06.0. That is useful, but it cannot establish which clip came first.

Inspect the exported signal

The code below reads the first channel of a 16-bit PCM WAV and counts upward zero crossings in three half-second windows. The windows sit inside the clips, away from the joins. This is a simple identifier for clean test tones; it is not a general pitch detector for songs.

import struct, wave

with wave.open("reordered.wav", "rb") as w:
    assert w.getsampwidth() == 2, "This checker expects 16-bit PCM"
    rate, channels, frames = w.getframerate(), w.getnchannels(), w.getnframes()
    values = struct.unpack("<" + "h" * frames * channels, w.readframes(frames))
    mono = values[::channels]

print("rate, channels, frames, seconds:", rate, channels, frames, frames / rate)
observed = []
for start in (0.25, 2.25, 4.25):
    window = mono[round(start * rate):round((start + 0.5) * rate)]
    count = sum(a <= 0 < b for a, b in zip(window, window[1:]))
    observed.append(count / 0.5)
print("estimated frequencies:", observed)
assert all(abs(a - b) <= 4 for a, b in zip(observed, (880, 220, 440)))

My downloaded file produced:

rate, channels, frames, seconds: 44100 2 264597 5.999931972789116
estimated frequencies: [880.0, 218.0, 440.0]

A half-second counting window has roughly 2 Hz resolution, and a crossing near a window boundary affects the count. The middle value is consistent with the 220 Hz fixture under this deliberately loose tolerance. The order check passes for this file.

There are two other observations to preserve: the output is 44.1 kHz stereo rather than 48 kHz mono, and its frame count is three below exactly six seconds at 44.1 kHz. The interface rounds its duration. I therefore would not describe this export as preserving the original sample format or as sample-perfect concatenation. Checking sequence and checking exact sample continuity are different tests.

Turn the fixture into a useful delivery check

For a real music reel, keep a written clip order and identify a recognizable phrase inside each segment. Review those landmarks in the downloaded file, not just in the editor. Listen separately to the transitions: a sequence check does not reveal clicks, awkward harmony, or unwanted overlaps.

If the frequency check fails, first inspect whether the files were actually moved, whether a trim or fade was enabled, and whether you are checking the newest download. Do not widen the tolerance until an unexplained result passes. If you intentionally use crossfades, recompute the expected window positions because overlap changes where later clips begin.

For a rebuildable record of inputs and trims, see how to write a clip manifest before joining audio. For choosing the editorial order of musical excerpts rather than testing their export, see a four-clip listening-reel planning note, in Japanese.

How to Test Whether Audio Conversion Preserves Leading and Trailing Silence

Alex Creatune — Mon, 26 Oct 2026 06:36:09 +0000

A converted music cue can have the right audible notes while starting too early on a timeline. Leading silence may be an intentional placement offset, and trailing silence may reserve space before the next clip. Checking only the displayed duration can miss the distinction.

I’m Alex from the Creatune team. I tested our public Audio Converter with a self-created file containing one second of silence, two seconds of a 440 Hz tone, and one more second of silence. This is a file measurement, not a listening test or a generated-music quality claim.

Build a source with known boundaries

This Python script uses only the standard library. It creates a four-second, mono, 48 kHz, 16-bit PCM WAV. The tone amplitude is deliberately modest.

import math
import struct
import wave

rate = 48000
samples = []
for i in range(4 * rate):
    value = 0
    if rate <= i < 3 * rate:
        value = round(8192 * math.sin(2 * math.pi * 440 * i / rate))
    samples.append(value)

with wave.open("silence-tone-silence.wav", "wb") as f:
    f.setparams((1, 2, rate, 0, "NONE", "not compressed"))
    f.writeframes(b"".join(struct.pack("<h", x) for x in samples))

The first tone sample is itself zero because the sine starts at a zero crossing. A nonzero-sample detector therefore need not report exactly 1.000000 seconds, even for this controlled source.

Convert once, then inspect the saved file

Open Creatune Audio Converter, choose the generated WAV, select FLAC from Output format, and download it. The public page currently lists MP3, WAV, M4A, FLAC, and OGG as input types, with a 50 MB / five-minute limit per file, or 2.5 minutes on small screens. The page states that this local conversion stays on the device.

For this run I reloaded the downloaded FLAC into the same converter. Both views showed 4.0 seconds and a central block of tone, but that rounded display was only a first check.

Decode the FLAC for a reproducible PCM inspection. This command requires FFmpeg to be installed:

ffmpeg -i silence-tone-silence-converted.flac -c:a pcm_s16le converted-decoded.wav

Use a small threshold rather than treating every nonzero sample as meaningful activity. Here, 32 in signed 16-bit PCM is about −60.2 dBFS. It is a test choice, not a universal definition of silence.

import array
import sys
import wave

for name in ("silence-tone-silence.wav", "converted-decoded.wav"):
    with wave.open(name, "rb") as f:
        assert f.getsampwidth() == 2
        rate, channels, frames = f.getframerate(), f.getnchannels(), f.getnframes()
        samples = array.array("h", f.readframes(frames))
        if sys.byteorder != "little":
            samples.byteswap()
    active = [i // channels for i, x in enumerate(samples) if abs(x) > 32]
    bounds = None if not active else (min(active) / rate, max(active) / rate)
    print(name, rate, channels, frames, frames / rate, bounds)

The channel division turns interleaved sample positions into frame positions. A frame is treated as active if any channel crosses the threshold.

What this run actually showed

Measurement	Source WAV	Decoded FLAC
Sample rate	48,000 Hz	44,100 Hz
Channels	1	2
Frames	192,000	176,399
Duration	4.000000 s	3.999977 s
First active frame, in seconds	1.000021	1.000023
Last active frame, in seconds	2.999979	2.999977

At the stated threshold, both silent regions remained approximately one second long. The file also changed sample rate and channel count, and its duration was approximately one 44.1 kHz frame shorter than four seconds. This test therefore supports a narrow conclusion about silence boundaries in this run. It does not establish sample-for-sample identity or preservation of the source format parameters.

FLAC’s lossless coding does not mean every conversion workflow preserves the exact source samples before encoding. Decoding, resampling, and channel handling are separate steps worth checking.

Make the acceptance rule fit the cue

For a cue aligned to video, define an allowed timing tolerance before testing. For sample-aligned stems, a much stricter rule may be necessary, including fixed sample rate, channel layout, and frame count. Do not round away a discrepancy simply because the interface displays one decimal place.

For real recordings, low-level room noise and reverb tails complicate the threshold. Inspect the waveform and listen to the final export before removing anything. Intentional silence, quiet decay, and unwanted empty space are different editing decisions.

Related workflows from our team

Our audio delivery contract checklist (English) explains why a file extension is not enough to specify a handoff. Add silence-boundary tolerances to that delivery note when timeline placement matters.

Our start, end, and decay-tail planning note (Japanese) helps decide which boundary is intentional before you test whether a conversion preserved it. A precise measurement is useful only after you know what should remain.

Why an Exact Audio Cut Can Still Have a Rough Edge

Alex Creatune — Sun, 25 Oct 2026 04:40:18 +0000

A clip can be exactly one second long and still need attention at its boundaries. Duration answers “how much audio did I keep?” It does not answer “what happens when playback jumps from silence into the first sample, or from the last sample back to silence?”

I’m Alex, part of the Creatune team. On October 24, 2026, I used our public browser audio cutter to export a synthetic test signal and inspected the saved WAV. I did not listen to the result. The numbers below demonstrate a boundary condition, not a claim that a click was audible.

Make a source with known properties

This Python script creates four seconds of a 440 Hz sine wave: mono, 48 kHz, signed 16-bit PCM, approximately one-quarter of full scale. It uses only the standard library and contains no recorded speech or copyrighted music.

import math
import struct
import wave

rate = 48000
samples = [round(0.25 * 32767 * math.sin(2 * math.pi * 440 * i / rate))
           for i in range(4 * rate)]
with wave.open("reference-440hz.wav", "wb") as out:
    out.setnchannels(1)
    out.setsampwidth(2)
    out.setframerate(rate)
    out.writeframes(struct.pack("<" + "h" * len(samples), *samples))

The amplitude is a property of the file, not a safe listening-volume guarantee. Set playback volume conservatively if you audition it.

Cut at times that are not waveform zero crossings

In Creatune Audio Cutter, select the source file. The page states that processing stays on the device. The public interface supports Start and End values in seconds plus an output-format selector.

Set Start to 0.01 and End to 1.01, choose WAV, and click Download. Those times request a one-second segment. In this run, the interface showed Total: 1.0 s.

No fade or zero-crossing control was visible in the interface I checked. Selecting a time is not the same as asking the editor to move it to the nearest waveform crossing.

Inspect the exported file, not just the timer

Save the download as cut-001-101.wav, then run this reader. It deliberately supports only 16-bit PCM; it stops rather than misinterpreting a different sample width.

import struct
import wave

with wave.open("cut-001-101.wav", "rb") as src:
    channels = src.getnchannels()
    rate = src.getframerate()
    frames = src.getnframes()
    assert src.getsampwidth() == 2, "This reader expects 16-bit PCM"
    raw = src.readframes(frames)
values = struct.unpack("<" + "h" * (len(raw) // 2), raw)
print("rate, channels, frames:", rate, channels, frames)
print("duration:", frames / rate)
print("first frame:", values[:channels])
print("last frame:", values[-channels:])
print("largest absolute sample:", max(map(abs, values)))

Observed values from this export:

rate, channels, frames: 44100 2 44100
duration: 1.0
first frame: (4815, 4815)
last frame: (5220, 5220)
largest absolute sample: 8192

The output was 44.1 kHz stereo, even though the source was 48 kHz mono. That is an observation from this browser run, not a promise about every export. It is also why the duration calculation uses the saved file’s sample rate rather than the input rate.

The first and last values are about 0.147 and 0.159 when divided by 32768. Both are clearly nonzero. An abrupt transition between digital silence and a nonzero signal can introduce a discontinuity and broadband energy. Whether that becomes an objectionable click depends on the signal, playback path, and listening context. The measurement alone does not establish audibility.

Looping adds another question: the transition is from the final sample to the first, rather than to silence. Nonzero endpoints do not by themselves prove a bad loop, and even matching endpoint values do not guarantee that their slopes or musical phrasing match.

Turn the measurement into an editing decision

For a real music excerpt, inspect the opening and ending in the context where the clip will play. A clean-looking boundary can still cut off a consonant, drum attack, or reverb tail. Keep the original so an attempted repair does not become the only copy.

If a boundary is objectionable, use an audio editor with the appropriate controls to move the cut, find a suitable zero crossing, or apply a short fade. A few milliseconds can be a starting point for a click-reduction fade, but choose its duration by listening; a longer musical fade serves a different purpose. Zero-crossing edits also need care with stereo material because the channels may not cross zero together.

After any adjustment, export again, verify the required duration, and audition the final file. Do not claim a fade was applied merely because the trimmed file has the right length.

Related workflows from our team

For planning which musical material to keep, our start, end, and decay-tail planning note (Japanese) separates source timestamps from placement in a video. It complements the sample-boundary check here.

If the excerpt comes from a separated practice backing track, How to Make a Karaoke Backing Track from a Song You Can Use (English) explains what to check at the vocal entrance and final reverb tail before trimming. Separation residue and a discontinuity from cutting are different problems, so keep those checks separate.

WAV vs FLAC: How to Check Whether Smaller Files Contain the Same Audio

Alex Creatune — Fri, 23 Oct 2026 02:08:19 +0000

You have a finished audio file to store or hand over. FLAC can be smaller than WAV, but file size alone cannot tell you whether the exported audio stayed the same. A useful check compares the decoded samples in a common representation.

I'm Alex from the Creatune team. I used the logged-out Creatune Audio Converter to export the same self-created six-second test tone as WAV and FLAC, then inspected both files with FFmpeg. This is a file and sample comparison, not a listening test or a claim about every possible input.

What the two formats store

A WAV container commonly carries uncompressed PCM audio. FLAC compresses audio losslessly: decoding a correctly encoded FLAC stream recovers the samples represented by that stream. That does not establish that an entire conversion pipeline preserved the source's original channel count, sample rate, or metadata.

For a handover, define what must match before comparing files:

Required: same duration, sample rate, channels, and decoded samples
Separately check: filename, tags, artwork, and receiving-app compatibility
Keep: the original source

Export the same source twice

My source was a six-second, mono, 44.1 kHz, 16-bit PCM WAV. A simple tone is useful for a controlled comparison, although its compression ratio will not represent a dense music mix.

Open the converter and choose a local audio file you can use.
Wait for the waveform and duration to appear.
Open Output format, choose WAV, and download it.
Keep the same loaded source, switch Output format to FLAC, and download again.

The page lists MP3, WAV, and FLAC as output choices. It describes local editing as free without generation credits and warns that edits are not saved after leaving the page.

Name the downloads converted.wav and converted.flac before running the commands below.

Inspect the output properties first

ffprobe -v error -select_streams a:0   -show_entries stream=codec_name,sample_rate,channels,duration   -of json converted.wav

ffprobe -v error -select_streams a:0   -show_entries stream=codec_name,sample_rate,channels,duration   -of json converted.flac

Actual results from this run:

Property	WAV	FLAC
File bytes	1,058,444	312,116
Duration	6.000000 s	6.000000 s
Sample rate	44,100 Hz	44,100 Hz
Channels	2	2
Codec	pcm_s16le	flac

Both exports were stereo even though the source was mono. Therefore, this test compares the two exports; it does not demonstrate source-format preservation. That distinction matters if a recipient specifically needs mono delivery.

Compare the decoded samples

FFmpeg is required for this example. Decode both outputs into the same signed 16-bit little-endian representation, without forcing a new sample rate or channel count:

ffmpeg -v error -i converted.wav -map 0:a:0   -c:a pcm_s16le -f s16le wav.pcm
ffmpeg -v error -i converted.flac -map 0:a:0   -c:a pcm_s16le -f s16le flac.pcm

Then use Python's standard library to compare them:

from pathlib import Path
import hashlib

wav = Path("wav.pcm").read_bytes()
flac = Path("flac.pcm").read_bytes()
print(len(wav), len(flac))
print(wav == flac)
print(hashlib.sha256(wav).hexdigest())
print(hashlib.sha256(flac).hexdigest())

The actual output length was 1,058,400 bytes for each decoded file. The sample bytes matched, and both SHA-256 hashes were:

3f1cf67d5bf71afc47a0befa8f6a9e7722fba804ad92ce5cdeca05afce755628

This establishes equality in the tested 16-bit decoded representation. For higher-bit-depth material, choose an appropriate comparison representation rather than silently discarding precision.

Use the result in a delivery decision

For this particular tone, FLAC used about 29.5% of the WAV file's storage while decoding to the same tested sample bytes. Real music, silence, and noise compress differently. Do not turn that percentage into a general promise.

Use WAV when the receiving workflow asks for it; use FLAC when lossless compressed storage and application support suit your needs. Check tags and artwork separately because decoded PCM equality says nothing about metadata. Keep the source, especially when the output channel configuration differs.

How to Tell Silence Trimming from a Crossfade in an Audio Join

Alex Creatune — Thu, 22 Oct 2026 11:55:21 +0000

Two clips can produce a shorter file even when neither clip has a fade enabled. Before blaming an export bug, check whether the joiner removed silence around the boundary.

I'm Alex from the Creatune team. On October 22, 2026, I tested the logged-out Audio Joiner with two synthetic WAV files that I created. I downloaded both outputs and measured their frame counts. This is a duration check, not a listening evaluation or a test of every possible source format.

Build a fixture with a known gap

Each file below is four seconds long: one second of digital silence, two seconds of tone, and one more second of silence. A uses 440 Hz; B uses 660 Hz. Neither contains someone's recording or voice.

import math, struct, wave

rate = 44100
for name, frequency in [('clip-a.wav', 440), ('clip-b.wav', 660)]:
    with wave.open(name, 'wb') as w:
        w.setparams((1, 2, rate, 0, 'NONE', 'not compressed'))
        data = bytearray()
        for n in range(4 * rate):
            sample = round(6000 * math.sin(2 * math.pi * frequency * n / rate)) if rate <= n < 3 * rate else 0
            data.extend(struct.pack('<h', sample))
        w.writeframes(data)

A direct A-then-B join has eight seconds in total. Its middle contains two seconds of silence: A's trailing second followed by B's leading second. The outer silence is a separate part of the fixture.

Export a baseline before changing one control

Open Creatune Audio Joiner, choose the two files, and keep A before B. Leave each Start at 0 and End at 4. Keep Fade in and Fade out disabled on both clips, and leave Trim silence at joins unchecked. Choose WAV and download the baseline.

Now enable only Trim silence at joins. Leave order, start/end values, fades and output format unchanged. The interface displayed a total of 0:06.0. Download this second version under a different filename.

Measure the files rather than the rounded label

import wave
for name in ['join-untrimmed.wav', 'join-trimmed.wav']:
    with wave.open(name, 'rb') as w:
        print(name, w.getnframes(), w.getframerate(),
              w.getnchannels(), w.getnframes() / w.getframerate())

For my two downloaded files, the measurements were:

Version	Frames	Sample rate	Channels	Seconds
Trimming off	352800	44100	2	8.000000
Trimming on	265481	44100	2	6.019977

The inputs were mono; both exported WAV files were stereo. That channel change is another reason to inspect the saved file instead of assuming the input properties survived unchanged.

The trimmed output was about 1.980 seconds shorter. It was not exactly six seconds, although the interface rounded to 0:06.0. This experiment establishes that duration changed when that one checkbox changed. It does not establish the internal silence threshold or guarantee identical behavior for noise, reverberation or compressed sources.

Why this is different from a crossfade

Silence trimming removes material judged to be silent near a join. A crossfade overlaps the ending of one clip with the beginning of the next while their levels change. Both can shorten a timeline; the causes are different.

The page explains that a crossfade uses Fade out on one clip and Fade in on the next. Those controls stayed off in this experiment. If both trimming and fades are enabled in a real project, disable them separately in copies to identify which change affects the result.

For a music reel, do not assume that every quiet interval is disposable. A breath, deliberate pause or reverb tail can be part of the timing. Save an untrimmed baseline, compare the actual join at a comfortable level, and choose the version that serves the edit. I did not perform that listening comparison here.

Related workflows from our team

Planning four clips as one audition reel (Japanese) explains the order and purpose of the clips before you change their boundaries.
How to Give an Unfinished Song a Clear Musical Ending (English) helps distinguish an intended musical ending from simply shortening a file.

DEV Community: Alex Creatune

How to Fit a Christmas Song into a 30-Second Video: Measure, Then Cut

What you need

Step 1: Describe the song and download it

Step 2: Measure the source

Step 3: Cut the section

Step 4: Verify the cut

Questions that come up

Related reading from our team

What Does 24-bit PCM Mean? Check Sample Width After a WAV Export

Put bit depth, sample rate, and channels in separate fields

Create a source with known properties

Convert the fixture and retain both files

Read the downloaded metadata

Turn the requirement into a reproducible decision

How to Check Audio Duration After a Speed Change: Why 0.8 Takes 25% Longer

Start with the inverse relationship

Make a source whose duration you know

Export two settings from the same original

Count frames in the downloaded files

Diagnose a mismatch without guessing

Related checks

A Fade-Out Is Not Yet a Crossfade: Test the Timeline Before Shipping Audio

Make two clips whose lengths are unambiguous

Test A: fade out only

Test B: enable the matching fade-in

Verify the files, not just the rounded UI

Turn the distinction into a delivery check

Joining Audio Is Not Mixing: Verify the Difference with Two Tones

Write the expected timeline before choosing a tool

Make a test whose parts are easy to identify

Inspect duration and two interior windows

Use the result to choose the next operation

Why a Healthy Stereo Waveform Can Disappear in Mono

Build a deliberately extreme control

Pass it through an explicit WAV conversion

Measure channels before measuring their sum

Use the result to isolate a real delivery problem

How to Check Duration When Joining 44.1 kHz and 48 kHz Audio

Make the mismatch deliberate

Set up a direct join

Measure seconds before comparing frames

Decide what this test should catch

Related checks

How to Verify Clip Order in a Joined Audio File with Three Test Tones

Create three identifiable inputs

Rearrange the clips in Creatune

Inspect the exported signal

Turn the fixture into a useful delivery check

How to Test Whether Audio Conversion Preserves Leading and Trailing Silence

Build a source with known boundaries

Convert once, then inspect the saved file

What this run actually showed

Make the acceptance rule fit the cue

Related workflows from our team

Why an Exact Audio Cut Can Still Have a Rough Edge

Make a source with known properties

Cut at times that are not waveform zero crossings

Inspect the exported file, not just the timer

Turn the measurement into an editing decision

Related workflows from our team

WAV vs FLAC: How to Check Whether Smaller Files Contain the Same Audio

What the two formats store

Export the same source twice

Inspect the output properties first

Compare the decoded samples

Use the result in a delivery decision

Related reading from our team

How to Tell Silence Trimming from a Crossfade in an Audio Join

Build a fixture with a known gap

Export a baseline before changing one control

Measure the files rather than the rounded label

Why this is different from a crossfade

Related workflows from our team