DEV Community: Alex Creatune

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.

Why local audio generation feels slower than the math says

Alex Creatune — Tue, 20 Oct 2026 16:42:01 +0000

Every time someone benchmarks an audio model on a laptop, the same thing happens: the spec sheet says real time, the stopwatch disagrees, and the gap gets blamed on "optimization".

Most of the time the model is fine. The bottleneck is memory traffic, and you can estimate it before you run anything.

The number that actually matters

A diffusion-style audio model does not touch its weights once per track. It touches them once per denoising step.

Take a 1.5B parameter model at fp16. That is roughly 3 GB of weights. If the sampler runs 1,500 steps, the model streams about 4.5 TB through the memory bus to produce a single clip.

Now divide by real bandwidth. A laptop with 150 GB/s of unified memory gets:

4.5 TB / 150 GB/s = 30 seconds

That is RTF ~ 1.0 — exactly real time, with no optimization and no discrete GPU. The spec sheet and the stopwatch agree once you account for the right quantity.

Why quantization moves the needle so much

The step count is fixed by the sampler. The bytes per step are not.

At 4-bit weights the same model is roughly 0.75 GB. Same 1,500 steps, same bus:

0.75 TB / 150 GB/s = 5 seconds

RTF drops to about 0.4. Nothing about the architecture changed. You moved four times fewer bytes, so you finished four times sooner. "We quantized it and it got 3x faster" is not a trick, it is arithmetic.

What actually surprises people

Two things get misattributed constantly.

Long clips do not scale linearly in quality. Most models are trained on short windows. Past roughly 30 seconds, structure starts to drift: the same chord loop returns, a vocal stops matching the lyric. That is a modeling limit, not a speed problem, and quantization will not touch it.

First-run latency is not throughput. Loading weights from disk is a one-time cost. If your first generation takes 40 seconds and the second takes 12, you were measuring cold start.

Measure these three

RTF — generation seconds divided by audio seconds
Peak RSS — whether the model fits, or spills into swap
Bytes per step — the quantity you can predict before running anything

If RTF is worse than bytes divided by bandwidth predicts, the problem is somewhere else: swap, a CPU fallback, or a sampler doing more work than you assumed.

The useful habit is to do this division before you install anything. It tells you in thirty seconds whether the model can run at real time on the machine you already own, and it tells you which knob will help.

Disclosure: I work on Creatune AI Music Generator. This arithmetic is the same one we use when deciding what to run locally.

What Does a Song Key Estimate Mean? A Reproducible C-Major Scale Check

Alex Creatune — Tue, 20 Oct 2026 06:16:50 +0000

A key finder may show a primary label and several alternatives. That does not mean the recording contains all of those keys, and the first label is not a substitute for checking the tonal centre.

I’m Alex from the Creatune team. On October 20, 2026, I tested the signed-out Creatune Key & BPM Finder with a synthetic eight-second scale that I created locally. This is one controlled input, not an accuracy benchmark or a test of a full musical mix. I inspected the displayed results; I did not conduct a listening evaluation.

Pitch collection and tonal centre are different

C major uses the notes C, D, E, F, G, A, B. A natural minor uses the same pitch classes, starting from A. The shared note collection alone cannot tell you which note functions as home. Phrase endings, harmony, bass movement, note duration, and emphasis provide additional context.

Also distinguish a key estimate from a chord chart. “C Major” does not tell you which chord occurs at second four, whether the song modulates later, or which notes a melody uses at each instant.

Build an input whose contents you know

This Python script uses only the standard library. It writes mono, 16-bit PCM at 44,100 Hz: one second each of C4, D4, E4, F4, G4, A4, B4, C5. Short envelopes soften the boundaries. It is deliberately simple and contains no borrowed recording.

import math
import struct
import wave

sample_rate = 44100
notes = [60, 62, 64, 65, 67, 69, 71, 72]
samples = []
for midi in notes:
    frequency = 440 * 2 ** ((midi - 69) / 12)
    for i in range(sample_rate):
        t = i / sample_rate
        envelope = max(0, min(1, t / 0.02, (1 - t) / 0.05))
        value = 0.25 * 32767 * envelope * math.sin(2 * math.pi * frequency * t)
        samples.append(int(value))

with wave.open("c-major-scale.wav", "wb") as out:
    out.setnchannels(1)
    out.setsampwidth(2)
    out.setframerate(sample_rate)
    out.writeframes(struct.pack("<" + "h" * len(samples), *samples))

The file is 352,800 frames long. That is eight seconds because duration equals frames divided by sample rate. A scale is useful for checking this narrow input; it is not representative of drums, dense harmony, detuned instruments, or changing keys.

Run the public workflow

Choose audio, select the generated WAV, and confirm the displayed filename and 8.0-second duration. Then click Analyze audio. I did this without signing in or spending generation credits.

The displayed result was C Major, with A Minor / G Major listed as other possibilities. The page also displayed 60.1 BPM and alternatives 30.1 / 120.2. That tempo observation is separate from the key question; one note starts every second in this fixture.

C Major agrees with the way this input was constructed. A Minor shares its pitch collection. G Major being offered does not establish that the input contains an F-sharp, nor does it reveal how the tool computed its alternatives. I am reporting the interface, not claiming knowledge of its scoring process.

Use the result as a candidate for the next check

For a real song, record the filename, section, primary estimate, and alternatives. Then check whether the melody and bass settle convincingly on the proposed home note. If the song changes tonal centre, analyse meaningful sections instead of forcing the whole recording into one label.

Do not turn a successful scale check into a percentage accuracy claim. The result does not test relative-minor discrimination, full-mix separation, or modulation. Those require additional inputs with known context and a defined evaluation method.

A useful note might read: “Tool suggests C major; A minor is an alternative; chorus ending still needs listening confirmation.” That is a more honest handoff than “Key verified: C major” when all you have done is press Analyze.

How to Record an AI Music Detector Result Without Turning It into a Verdict

Alex Creatune — Mon, 19 Oct 2026 03:51:47 +0000

Suppose a music-submission workflow includes an AI detector. A number comes back. What should your application save, and what should a reviewer conclude?

The safe engineering distinction is between a measurement from a particular file and a claim about how a song was made. Changing the export can change a measurement without changing the song’s history.

I’m Alex from the Creatune team. This is a review-workflow template based on the public AI Music Detector interface checked on October 19, 2026. No detector result or accuracy benchmark is presented here; I did not submit a test recording in this walkthrough.

Start with the original authorized file

Creatune AI Music Detector accepts one MP3, WAV, FLAC, OGG, M4A, or AAC file up to 50 MB. Its public page says recordings longer than five minutes are checked only for the first five minutes. The interface does not require an account or credits.

Use a file you are permitted to upload. Prefer the earliest available export and retain it unchanged. Record whether it is a mastered release, a compressed preview, or a source export. Those descriptions are useful review context, not alternative labels for “human” and “AI.”

Preserve a useful record

After a check, copy the displayed score, displayed label, analysis date, and any duration warning. The public page says there is no result history, so leaving the page is not a reliable way to preserve the observation.

A minimal record can follow this template:

{
  "file_sha256": "<hash of the exact submitted bytes>",
  "source_description": "<original export, preview, or other>",
  "checked_at": "<actual timestamp>",
  "displayed_score": null,
  "displayed_label": null,
  "analyzed_duration_note": "<copy the actual notice>",
  "review_status": "needs_context"
}

The nulls deliberately mean no observation yet. Do not fill a result field with an expected score or convert a failed request into a zero.

You can fingerprint a local file with Python before uploading:

from hashlib import sha256
from pathlib import Path

path = Path("authorized-export.wav")
print(sha256(path.read_bytes()).hexdigest())

A hash identifies identical bytes. It neither proves authorship nor detects AI generation. A fresh export of the same performance will generally have a different hash.

Keep “inconclusive” as a real outcome

The public guide distinguishes likely AI-generated, inconclusive, and likely not AI-generated. Preserve the returned label rather than inventing a second threshold rule in your application.

A high score is a reason to ask for context, such as project files, stems, source disclosures, and export history. A low score does not rule out newer generators, hybrid workflows, or processing that changed the relevant signal. The score is not a calibrated statement that a song has a particular probability of being AI-created.

Separate transport failure from musical evidence

Your review state should distinguish at least:

Not checked: no request completed.
Request failed: a technical problem prevented a result.
Result recorded: score and label were captured from the exact file.
Reviewed with context: a person considered additional evidence.

If a WAV and MP3 receive different scores, keep both records with their hashes and export descriptions. Do not average them into an “authorship score.” Re-encoding repeatedly until a preferred label appears is also not a valid provenance test.

This workflow makes a result auditable without overstating it. A detector can contribute one technical observation; production history and human review answer a broader question.

How to Check Whether an Audio Conversion Preserved Left and Right Channels

Alex Creatune — Sun, 18 Oct 2026 04:12:17 +0000

A WAV file can report two channels even when both contain the same mono signal. If your next step depends on stereo placement, checking the channel count is only the beginning.

I'm Alex from the Creatune team. On October 18, 2026, I tested our public Audio Converter with a small file that contains a different tone on each side. This is a reproducible signal test, not a listening review or a claim about every supported format.

Give each channel an identity

A useful fixture has a known duration, sample rate, channel order and signal on each side. This one uses:

Three seconds of 16-bit PCM at 48,000 Hz.
Left: a 440 Hz sine wave with amplitude 0.18.
Right: a 660 Hz sine wave with amplitude 0.12.

The different frequencies make a channel swap, mono sum or duplicated channel easier to detect. The different amplitudes provide a second check. These are deliberately simple test signals; they do not represent music quality.

import math, struct, wave
sr = 48000
with wave.open("stereo-test.wav", "wb") as w:
    w.setparams((2, 2, sr, 0, "NONE", "not compressed"))
    frames = []
    for i in range(3 * sr):
        left = round(0.18 * math.sin(2 * math.pi * 440 * i / sr) * 32767)
        right = round(0.12 * math.sin(2 * math.pi * 660 * i / sr) * 32767)
        frames.append(struct.pack("<hh", left, right))
    w.writeframes(b"".join(frames))

Convert one controlled file

Open the converter, choose the fixture, and check that its displayed duration is 3.0 seconds. Select WAV in Output format, then choose Download. Save the result separately from the original.

The page currently offers MP3, WAV and FLAC output. It says local audio stays on the device and lists 50 MB per file, up to five minutes, or 2.5 minutes on small screens. This test covers the WAV path only.

Read the samples, not just the label

The following checker is intentionally limited to uncompressed 16-bit WAV and these steady test tones. It separates interleaved channel samples and estimates frequency by counting positive-going zero crossings.

import struct, wave

def inspect(path):
    with wave.open(path, "rb") as w:
        channels, sr, n = w.getnchannels(), w.getframerate(), w.getnframes()
        assert w.getsampwidth() == 2
        samples = struct.unpack("<" + "h" * (n * channels), w.readframes(n))
    print(path, "channels", channels, "rate", sr, "seconds", n / sr)
    for c in range(channels):
        a = samples[c::channels]
        crossings = sum(a[i - 1] <= 0 < a[i] for i in range(1, n))
        print(c, "peak", max(abs(x) for x in a) / 32768,
              "approx Hz", crossings / (n / sr))

inspect("stereo-test.wav")
inspect("converted.wav")

Measurement	Input	Downloaded WAV
Duration	3.000 s	3.000 s
Channels	2	2
Sample rate	48,000 Hz	44,100 Hz
Left frequency estimate	440.00 Hz	439.67 Hz
Right frequency estimate	660.00 Hz	659.67 Hz
Left peak	0.17999	0.17999
Right peak	0.119995	0.119995

The downloaded file retained distinct left and right test signals, in the expected order. Counting whole crossings over three seconds has a resolution of roughly 0.33 Hz; the values above are not evidence of an audible pitch shift.

The sample rate changed, so this was not a bit-identical copy of the input. A WAV extension does not promise preservation of the source sample rate. If a receiving app requires 48 kHz, this observed output would need another suitable export path or conversion step.

Turn the test into an acceptance checklist

Before accepting an export, check duration, channel count, channel identity and the format requirements of the next application. If both sides show the same signal, investigate whether a mono conversion or channel duplication happened. If the frequencies appear on opposite sides, investigate channel order.

Do not apply this zero-crossing checker to arbitrary music and interpret its output as a reliable pitch estimate. Complex signals need more suitable analysis and a listening check. For a controlled conversion fixture, however, a few lines of code distinguish “two channels exist” from “the intended signals survived.”

How to Check a Pitch Shift Without Confusing It with Faster Playback

Alex Creatune — Sat, 17 Oct 2026 02:34:49 +0000

If a recording sounds higher after editing, did its pitch change, or did the whole recording simply play faster? A small test can separate those two possibilities: inspect both frequency and duration.

I'm Alex, part of the Creatune team. On October 17, 2026, I tested our public Pitch Changer with a locally created 440 Hz sine wave. This is a narrow functional check, not a listening-quality benchmark for vocals or full songs.

The two numbers to predict

In equal temperament, a shift of n semitones has frequency ratio:

ratio = 2 ** (n / 12)
expected_hz = input_hz * ratio

For 440 Hz and +12 semitones, the expected frequency is 880 Hz. A duration-preserving pitch shift should keep an 8-second input approximately 8 seconds long. Simple double-speed playback would also produce 880 Hz, but its duration would be about 4 seconds.

Make a known input

Use a quiet synthetic signal so the expected frequency is unambiguous. This standard-library Python script creates an 8-second, 48 kHz, mono, 16-bit PCM WAV:

import array
import math
import wave

rate = 48000
samples = array.array("h", (
    int(6000 * math.sin(2 * math.pi * 440 * i / rate))
    for i in range(rate * 8)
))
import sys
if sys.byteorder != "little":
    samples.byteswap()
with wave.open("tone-8s-48k.wav", "wb") as w:
    w.setparams((1, 2, rate, 0, "NONE", "not compressed"))
    w.writeframes(samples.tobytes())

This recreates the signal's test conditions; its exact amplitude need not match my fixture for the frequency and duration check.

Shift and export

Open Creatune's Pitch Changer, choose the WAV, and check that the input duration is 8.0 seconds.

Move Pitch (semitones) to +12 and verify the displayed number. Choose WAV under Output format, then Download. Checking the displayed value matters: changing focus or typing at a slider is not evidence that the setting changed.

The public page currently allows shifts from -12 to +12 semitones and describes local processing. Its stated file limit is 50 MB, with up to 5 minutes of audio, or 2.5 minutes on small screens.

Measure the saved file

For this pure sine wave, counting upward zero crossings over one middle second is a simple frequency estimate. Avoid the first instant of the file, where processing may have a transient.

import array
import sys
import wave

with wave.open("pitch-plus12.wav", "rb") as w:
    assert w.getsampwidth() == 2, "This example expects 16-bit PCM"
    rate, channels, frames = w.getframerate(), w.getnchannels(), w.getnframes()
    pcm = array.array("h", w.readframes(frames))
    if sys.byteorder != "little":
        pcm.byteswap()

left = pcm[::channels]
window = left[rate:2 * rate]
crossings = sum(a <= 0 < b for a, b in zip(window, window[1:]))
print("seconds:", frames / rate)
print("sample_rate:", rate)
print("channels:", channels)
print("estimated_hz:", crossings)

My actual input measured 8.0 seconds and approximately 440 Hz. The saved output measured:

seconds: 7.999977324263039
sample_rate: 44100
channels: 2
estimated_hz: 880

The output was one 44.1 kHz sample shorter than 8 seconds. It was also exported as stereo at 44.1 kHz, so I used the output header rather than assuming the input's sample rate or channel count.

What this result establishes

For this test file, the frequency doubled while duration remained approximately unchanged. That distinguishes the result from simple double-speed playback.

It does not establish that a shifted singer retains natural formants, that transients remain clean, or that every instrument sounds good at +12. Zero crossings are not a reliable general pitch detector for a full mix. After a basic functional check, compare real material at the small interval you actually need, listen for artifacts, and verify the saved duration again.

Does Converting MP3 to WAV Improve Quality? A Small Reproducible File Test

Alex Creatune — Fri, 16 Oct 2026 05:10:35 +0000

An editor asks for a WAV file, but you only have an MP3. Converting it can solve a format-compatibility problem. It does not reconstruct the information discarded when the MP3 was made.

I’m Alex from the Creatune team. Here is a small test using the public Creatune Audio Converter, checked while logged out on October 16, 2026. I used a generated sine wave, not a commercial song. The measurements concern file size and PCM format metadata; I did not perform a listening test or measure perceptual quality.

What changes when you convert?

MP3 is a lossy encoding format. A decoder produces samples from the encoded representation. Saving those samples as PCM WAV stores an uncompressed representation of that decoded audio, including the limitations already present in the source.

A larger file therefore does not establish better sound. Nor does a two-channel file prove that a mono source has gained genuine stereo information.

WAV is a container and can hold different encodings. In this test, the downloaded WAV was 16-bit PCM. Do not assume that every file with a .wav extension has the same properties.

Make an input you can reproduce

This Python 3 script creates an eight-second, 440 Hz sine wave: 48 kHz, one channel, 16-bit PCM.

import math
import struct
import wave

rate = 48000
with wave.open("tone-8s-48k.wav", "wb") as out:
    out.setnchannels(1)
    out.setsampwidth(2)
    out.setframerate(rate)
    out.writeframes(b"".join(
        struct.pack("<h", round(0.2 * 32767 * math.sin(2 * math.pi * 440 * n / rate)))
        for n in range(8 * rate)
    ))

This WAV is the reference. Keep it. Creating an MP3 here is just a way to obtain a controlled test input; if you already have a lossless master, use that master for a real WAV delivery instead of taking this detour.

Convert in the browser

Open Audio Converter and choose tone-8s-48k.wav.
Leave Output format as MP3 and click Download. Save it as tone-converted.mp3.
Choose that downloaded MP3 as the new input.
Select WAV and click Download. Save it as roundtrip.wav.

The page currently lists MP3, WAV, M4A, FLAC, and OGG as inputs, with MP3, WAV, and FLAC outputs. It states that local audio stays on the device. The displayed limit is 50 MB per file and five minutes, or 2.5 minutes on small screens.

The output choice is a format selection. This form did not expose separate sample-rate, bit-depth, or channel controls during the test.

I captured the FLAC selection to show the alternative; the measurements below are for the downloaded WAV, not a tested FLAC export.

Inspect the result, not just the extension

For the two PCM WAV files:

from pathlib import Path
import wave

for name in ("tone-8s-48k.wav", "roundtrip.wav"):
    with wave.open(name, "rb") as f:
        print(name, {
            "bytes": Path(name).stat().st_size,
            "frames": f.getnframes(),
            "rate": f.getframerate(),
            "channels": f.getnchannels(),
            "bits": f.getsampwidth() * 8,
            "seconds": f.getnframes() / f.getframerate(),
        })

These were the actual results of this run:

File	Bytes	Rate	Channels	Bit depth	Duration
Original WAV	768,044	48,000 Hz	1	16	8.000000 s
Intermediate MP3	321,984	Not measured here	Not measured here	Not applicable as a PCM bit depth	Not measured here
Round-trip WAV	1,419,308	44,100 Hz	2	16	8.045714 s

The final WAV contained 354,816 frames. Its audio payload size follows the PCM relationship:

354816 frames × 2 channels × 2 bytes = 1419264 bytes

The complete file was 44 bytes larger than that payload. File size is explained by the number of stored samples and their representation; it is not a quality score.

The final duration was about 45.7 ms longer than the original. Encoder delay, padding, and decoding behavior can matter in compressed-audio round trips, but this experiment does not isolate which stage caused this difference. Do not label the files sample-aligned without a separate check. The browser’s rounded “8.0 s” display also cannot reveal a difference this small.

Choose the next step from the actual requirement

Only WAV is accepted: conversion may be sufficient, followed by a playback check in the destination application.
48 kHz mono is required: this measured output does not meet those requirements. Use an export workflow with explicit controls and verify again.
Better fidelity is required: look for the original lossless source. Rewrapping a lossy source cannot supply it.
Exact sync is required: compare alignment and duration in the editing timeline; do not infer them from a rounded duration display.

This is one input and one browser run, not a promise that every conversion produces identical parameters. A useful conversion workflow ends with the file requirements you can verify, rather than the size you hoped would imply an improvement.

What Is BPM? Check a Tempo Estimate with a Reproducible Click Track

Alex Creatune — Thu, 15 Oct 2026 09:05:00 +0000

BPM means beats per minute. At 120 BPM, a beat occurs every half-second. That number is useful when matching music to cuts, setting a practice tempo, or comparing two loops—but a detector still has to decide which rhythmic level counts as the beat.

I’m Alex from the Creatune team. On October 15, 2026, I checked our public Key & BPM Finder with a synthetic input whose timing was known in advance. This is one reproducible test, not an accuracy benchmark for real music.

Build an input with a known pulse

The following standard-library Python script creates a 16-second, mono, 44.1 kHz PCM WAV. Each half-second begins with a short, decaying 1 kHz click. The timing is 120 clicks per minute; the tone frequency is not the tempo.

import math
import struct
import wave

rate = 44100
period = rate // 2
with wave.open("click-120bpm-16s.wav", "wb") as audio:
    audio.setnchannels(1)
    audio.setsampwidth(2)
    audio.setframerate(rate)
    samples = []
    for n in range(rate * 16):
        envelope = max(0, 1 - (n % period) / 1323)
        value = int(12000 * math.sin(2 * math.pi * 1000 * n / rate)
                    * envelope)
        samples.append(struct.pack("<h", value))
    audio.writeframes(b"".join(samples))

For the first click at 0 seconds and the 32nd at 15.5 seconds, there are 31 intervals. Calculating from these timestamps gives 60 * 31 / 15.5 = 120. Counting events and intervals as the same quantity is a common source of mistakes in short measurements.

Analyze the file

Open Creatune Key & BPM Finder, choose the WAV, and click Analyze audio. The public page says local audio stays on the device. Its displayed limits are 50 MB per file and five minutes, or 2.5 minutes on small screens.

My actual run returned 120.2 BPM, with alternatives 60.1 / 240.4. The estimated key was blank. The page also displayed “No reliable estimate. Try a longer musical section.” That message is part of the observed result; the numerical tempo should not be reported as an unqualified high-confidence answer.

The displayed tempo is 0.2 BPM above the designed pulse. That tells us what happened for this click file, not how the tool performs on a live band, a tempo change, or a dense mix. The file has no useful harmonic progression, so this is not a musical-key test.

Why can 60, 120, and 240 all appear?

A detector can group pairs of clicks into a slower pulse or interpret subdivisions as a faster one. Real music adds phrasing, accents, and syncopation. A repeated event every half-second does not, by itself, prove which notated beat a musician intends.

For an actual song:

Choose a section with a stable pulse, rather than a free-time intro.
Compare the displayed alternatives against the phrase and drum accents.
Use Tap the beat to mark the beat you intend, then compare that reading.
Check another section before applying one tempo to the entire song.

Tap tempo is a separate manual aid; I did not measure its accuracy in this test. If a live performance speeds up and slows down, one BPM value may be inadequate for an edit grid.

Turn the estimate into an editing check

For constant tempo, seconds_per_beat = 60 / BPM. Four bars of 4/4 contain 16 beats, so at 120 BPM they span 8 seconds. At 120.2 BPM the same calculation gives about 7.987 seconds. Do not silently replace a known designed tempo with an estimate simply because it has a decimal place.

BPM also does not specify where beat one starts. Align the first intended beat, then check whether later beats drift. For a loop or video edit, the useful question is whether the pulse stays aligned across the segment you actually use.

Verify a Gain Change with Sample Peaks Before Judging Loudness

Alex Creatune — Wed, 14 Oct 2026 07:41:59 +0000

A volume slider changes a setting. A saved file gives you something you can measure. For a small audio export check, a quiet synthetic fixture makes the relationship between the two easier to inspect than a finished song near full scale.

I’m Alex, part of the Creatune team. On October 14, 2026, I tested one WAV export from the public Audio Volume Changer. The measurements below come from that export. They are not a listening-quality score or a mastering recommendation.

Make a fixture with headroom

The input was eight seconds of mono PCM at 48 kHz: a 440 Hz tone for the first 0.1 seconds of each 0.5-second interval, otherwise silence. Its intended amplitude was 0.2 of full scale. Integer quantization made the measured sample peak 0.1999817, or approximately -13.9802 dBFS.

For a linear gain change, the expected amplitude ratio is:

ratio = 10 ** (gain_db / 20)
+6 dB -> approximately 1.9953
0.2 * 1.9953 -> approximately 0.3991

This leaves enough headroom that a simple +6 dB check should not need peak protection. It does not test how a limiter behaves near its threshold.

Change the control and export

I selected the fixture, moved the Volume (dB) control to +6, chose WAV and downloaded the result. The visible control spans -24 to +12 dB in one-dB steps. The page states that this is local processing, with a 50 MB limit and five minutes per file; small screens have a 2.5-minute limit.

One UI detail matters in automated checks: confirm the displayed dB value after moving the control. Changing only an input element’s value is not sufficient evidence that the application applied the change.

Read the output, including its new format

Property	Input	Downloaded output
Sample rate	48,000 Hz	44,100 Hz
Channels	1	2
Frames	384,000	352,799
Duration	8.000000 s	7.999977 s
Sample peak	0.1999817	0.3990479
Peak dBFS	-13.9802	-7.9795

The measured change was approximately +6.0007 dB. This is consistent with the requested gain for this fixture. The export also changed the sample rate and channel count, so comparing raw sample arrays one-to-one would be the wrong check.

For 16-bit PCM WAV files, the Python standard library is enough to inspect a peak:

import math
import struct
import wave

with wave.open("output.wav", "rb") as audio:
    assert audio.getsampwidth() == 2  # this example handles 16-bit PCM
    frames = audio.getnframes()
    rate = audio.getframerate()
    channels = audio.getnchannels()
    raw = audio.readframes(frames)

samples = struct.unpack("<" + "h" * (len(raw) // 2), raw)
peak = max(abs(value) for value in samples) / 32768
peak_dbfs = 20 * math.log10(peak) if peak else float("-inf")
print(frames / rate, rate, channels, peak_dbfs)

Keep the conclusion narrow

A sample-peak check cannot establish perceived loudness, true peak between samples, distortion audibility or intelligibility. A gain increase also raises existing noise. The page describes peak protection, but this fixture did not exercise it; it stayed well below full scale.

I also inspected the -6 dB setting, shown below, but did not export it. It is a useful next test condition, not a second measured result.

For a production clip, use this check to catch a gross gain mistake, then listen at a consistent playback level and measure whatever the delivery specification actually requires. Record the requested gain, the observed change and the output format separately. That gives the next person a reproducible result rather than a filename that merely says “louder.”

Check an Audio Cut by Its Frames, Not Its Filename

Alex Creatune — Tue, 13 Oct 2026 08:34:11 +0000

I’m Alex from the Creatune team. Here is a reproducible check of an actual browser audio cut, performed on October 13, 2026. The input is an original synthetic test signal, not AI-generated music. The lesson applies when delivering a chorus excerpt or a short reference clip: inspect the exported file before calling it finished.

Define the interval before opening the tool

My input was a 12-second, 48,000 Hz, mono, 16-bit PCM WAV: 576,000 frames and 1,152,044 bytes. The first and last half-seconds were silent; the middle contained sections of 440, 660, and 880 Hz tones. The selected interval was 3.25 to 8.75 seconds.

To create the same input without needing a song or a licensed sample:

import math
import struct
import wave

rate = 48000
samples = []
for i in range(rate * 12):
    t = i / rate
    hz = 440 if t < 4 else 660 if t < 8 else 880
    amplitude = 0.15 if 0.5 <= t < 11.5 else 0
    samples.append(round(32767 * amplitude * math.sin(2 * math.pi * hz * t)))

with wave.open("cutter-input-12s.wav", "wb") as out:
    out.setparams((1, 2, rate, 0, "NONE", "not compressed"))
    out.writeframes(struct.pack("<" + "h" * len(samples), *samples))

The duration target is simple:

expected_seconds = 8.75 - 3.25  # 5.5

At 48 kHz, that would be 264,000 frames. That frame count is only valid if the output rate is also 48 kHz.

Make the cut in the public interface

I opened Creatune Audio Cutter while signed out, selected the WAV from my device, filled “Start (s)” with 3.25 and “End (s)” with 8.75, selected WAV, and downloaded the result. The page stated that local audio stays on the device. Its visible limits were 50 MB per file and five minutes, or 2.5 minutes on small screens.

The time controls and output selection let you record a precise request. Clicking outside a numeric field before scrolling also avoids accidentally changing a focused value with the mouse wheel; check the fields again before download.

Read the downloaded file, without trusting its label

Python’s standard library can inspect this PCM WAV:

import wave

with wave.open("cut-3.25-8.75.wav", "rb") as audio:
    rate = audio.getframerate()
    frames = audio.getnframes()
    print("rate:", rate)
    print("channels:", audio.getnchannels())
    print("sample bytes:", audio.getsampwidth())
    print("frames:", frames)
    print("seconds:", frames / rate)
    assert abs(frames / rate - 5.5) <= 1 / rate

The actual output was:

rate: 44100
channels: 2
sample bytes: 2
frames: 242550
seconds: 5.5

The duration matches the request. The sample rate and channel count differ from the input. In this run, the correct expected count is 5.5 * 44100 = 242550, not 264,000. A frame contains one sample for each channel; adding a channel does not double the duration or frame count.

The file size was 970,244 bytes. For this particular simple WAV, 242,550 frames × 2 channels × 2 bytes accounts for 970,200 bytes of audio, with a 44-byte header. Do not assume every WAV has that header size: extra metadata chunks are allowed. Frame count and sample rate are the direct duration check.

Keep timing, format, and listening checks separate

This run verifies file duration and observed output parameters. It does not establish bit-perfect preservation, musical quality, or identical behavior across browsers. A recipient requiring 48 kHz mono still needs a file meeting that requirement, even if its duration is right.

For a real song excerpt, reopen the output in an audio editor and listen to the first and last moments. The arithmetic cannot tell you whether you cut off a consonant, an attack, or a reverb tail. Record those observations next to the technical check:

Requested interval:
Observed frames / sample rate / channels:
Observed duration:
Beginning and ending listening notes:
Recipient's required format:
Ready to deliver / changes needed:

Use a decoder or an appropriate audio probe for compressed formats; wave is not an MP3 inspector. A descriptive filename helps you find the clip. Reading its contents tells you what you actually exported.

Make a Small MP3 Reference Copy and Keep the WAV Ready for Editing

Alex Creatune — Fri, 09 Oct 2026 06:20:08 +0000

I’m Alex from the Creatune team. When a collaborator needs to hear an idea, a clearly named reference copy is useful: they can review the music while the editing source stays easy to find.

Here is a small, reproducible export exercise using the public Creatune Audio Converter. I used a self-created two-tone signal so the file can be recreated without a private recording, client material, or licensed song.

Create an identifiable source

This Python script creates eight seconds of mono audio at 44,100 Hz and 16-bit PCM. The first four seconds use 440 Hz; the next four use 660 Hz. A short fade at the beginning and end makes the file a convenient workflow fixture.

import math
import struct
import wave

rate = 44100
frames = rate * 8
samples = []
for i in range(frames):
    frequency = 440 if i < rate * 4 else 660
    envelope = min(1, i / 2205, (frames - 1 - i) / 2205)
    value = int(5000 * envelope * math.sin(2 * math.pi * frequency * i / rate))
    samples.append(struct.pack('<h', value))
with wave.open('reference-demo.wav', 'wb') as output:
    output.setparams((1, 2, rate, 0, 'NONE', 'not compressed'))
    output.writeframes(b''.join(samples))

This is a test signal for the export process, not a musical-quality benchmark. For an actual project, follow the same steps with your own authorized recording.

Export a listening copy

Open the converter, choose the WAV, select MP3 in Output format, and click Download. In this run, the source appeared as reference-demo.wav, with a displayed duration of 8.0 s.

The downloaded filename was reference-demo-audio-converter.mp3. I saved the local demonstration copy as reference-demo.mp3 for the next check.

File	Size in this run	Purpose
reference-demo.wav	705,644 bytes	Original editing source
reference-demo.mp3	321,984 bytes	Compressed reference copy

The MP3 was about 54% smaller for this particular signal and export. File-size differences will depend on the source and encoding settings; these numbers describe this run.

Reopen the exported file

I selected the downloaded MP3 in the same converter. It opened as reference-demo.mp3, displayed a waveform, and showed 8.0 s.

That confirms a usable export and reimport path in this session. The displayed duration is rounded; it is not a sample-accurate alignment measurement. This exercise did not include a listening comparison.

For a music handoff, also play the reference in the app your collaborator will use. Check the opening, the ending, and the musical section you want feedback on. Include one precise question, such as “Does the chorus entrance match the cut at 00:24?”

Name the copy for the decision it supports

An example handoff folder could contain:

evening_walk_v03_source.wav
evening_walk_v03_reference.mp3
evening_walk_v03_notes.txt

In the note, state the version, the purpose of the listening copy, and the question to answer. When an arrangement changes, make the next reference from the updated source and increase the version number.

The current public converter works locally in the browser and offers MP3, WAV, and FLAC output. Its page lists a 50 MB file limit, up to five minutes on larger screens and 2.5 minutes on small screens. Local editing uses no generation credits; download the result before leaving the page.

A reference export becomes much more useful when the audio file, version name, and feedback question all point to the same decision.