Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silent Detection Misses at File End #2191

Open
4 tasks done
7f5d3nbctkx8gcxwek9e7z3him6f44a7 opened this issue Oct 11, 2024 · 1 comment
Open
4 tasks done

Silent Detection Misses at File End #2191

7f5d3nbctkx8gcxwek9e7z3him6f44a7 opened this issue Oct 11, 2024 · 1 comment

Comments

@7f5d3nbctkx8gcxwek9e7z3him6f44a7

The fewer issues I have to read, the more new features I will have time to implement, so I ask that you please try these things first

Steps to reproduce

  1. Launch LosslessCut 3.63.0.0.
  2. Open an audio file with a silent section at the end. The file used is here: Test File
  3. Execute silent detection with a threshold of -60dB, duration of 2.0 seconds, and mode 1.
  4. After silent detection, execute "Invert all segments in timeline."

Expected behavior

The silent section should be correctly detected up to the end of the file, and no unnecessary segments should be created when inverting segments.

Actual behavior

A part at the end of the file remains undetected as silent, and executing "Invert all segments in timeline" results in a very short segment of 0ms, ? frames appearing at the end of the file.

Additional Information:
(I don't know where to write this, so I'll write it here.)

  • Checking the sample values at the end of the file shows they range from approximately -6 to 6 in 16-bit values, with no samples exceeding the silence detection threshold.
  • As a comparison, I used Audacity to cut the silent parts and generate a new silent section at the end of another file. When this file was processed with LosslessCut, it was correctly detected as silent up to the end without issues. The sample values were similarly in the range of -6 to 6 in 16-bit values, showing no apparent differences from the problematic file. The file used for this test is here: Comparison File
  • This issue has persisted since at least version 3.62.0.0, but it's unclear exactly when it started.

Provide an error report

No error occurred.

{
"err": false,
"state": {
"ffmpegExperimental": false,
"preserveMovData": false,
"movFastStart": true,
"preserveMetadataOnMerge": false,
"filePath": "C:\Users\read_\Downloads\test.wav",
"fileFormat": "wav",
"externalFilesMeta": {},
"mainStreams": [
{
"index": 0,
"codec_name": "pcm_s16le",
"codec_long_name": "PCM signed 16-bit little-endian",
"codec_type": "audio",
"codec_tag_string": "[1][0][0][0]",
"codec_tag": "0x0001",
"sample_fmt": "s16",
"sample_rate": "44100",
"channels": 1,
"bits_per_sample": 16,
"initial_padding": 0,
"r_frame_rate": "0/0",
"avg_frame_rate": "0/0",
"time_base": "1/44100",
"duration_ts": 633158,
"duration": "14.357324",
"bit_rate": "705600",
"disposition": {
"default": 0,
"dub": 0,
"original": 0,
"comment": 0,
"lyrics": 0,
"karaoke": 0,
"forced": 0,
"hearing_impaired": 0,
"visual_impaired": 0,
"clean_effects": 0,
"attached_pic": 0,
"timed_thumbnails": 0,
"captions": 0,
"descriptions": 0,
"metadata": 0,
"dependent": 0,
"still_image": 0
}
}
],
"copyStreamIdsByFile": {
"C:\Users\read_\Downloads\test.wav": {
"0": true
}
},
"cutSegments": [
{
"start": 0,
"end": 10.49535
},
{
"start": 14.3573,
"end": 14.357324
}
],
"mainFileFormatData": {
"filename": "C:\Users\read_\Downloads\test.wav",
"nb_streams": 1,
"nb_programs": 0,
"format_name": "wav",
"format_long_name": "WAV / WAVE (Waveform Audio)",
"duration": "14.357324",
"size": "1266634",
"bit_rate": "705777",
"probe_score": 99,
"tags": {
"title": "青木と髙橋のもうすぐ金になるラジオ #96",
"artist": "IFUKUBO ch",
"comment": "https://www.youtube.com/watch?v=mhC8t0fgGEM",
"date": "20241010"
}
},
"rotation": 360,
"shortestFlag": false,
"effectiveExportMode": "merge",
"outSegTemplate": "${FILENAME}-${CUT_FROM}-${CUT_TO}${SEG_SUFFIX}${EXT}",
"preserveMetadata": "default",
"preserveChapters": true
},
"platform": "win32",
"version": "3.63.0"
}

Share the file

https://drive.google.com/file/d/1QXZNls3ytXVZNnQEpOHsSYCewJRcgRUg/view?usp=sharing

Share log from developer tools

Version 3.63.0
App.tsx:1679 userOpenFiles
App.tsx:1680 C:\Users\read_\Downloads\test.wav
ffmpeg.ts:271 FFprobe detected format(s) wav
ffmpeg.ts:671 Trying to load timecode
App.tsx:1332 loadMedia C:\Users\read_\Downloads\test.wav C:\Users\read_\Music\radio undefined
App.tsx:543 State reset
useVideo.ts:105 onDurationChange 14.357324
useSegments.ts:106 silentScenes [{…}]

-I am not sure as this is my first time reporting a bug, but is this the right information to paste?

-I noticed after pasting, perhaps this should be reported to ffmpeg rather than losslesscut?

@mifi
Copy link
Owner

mifi commented Nov 29, 2024

Sorry for the delay and thanks for your detailed report. I can confirm that when inverting, it creates a short segment at the end. this is the segment:

      start: 14.3573,
      end: 14.357324,

this is because ffmpeg reports the silent segment as being from 10.495 to 14.3573, however the total duration of the audio is 14.357324, so there's a small gap at the end.

If I run the silence detect command on ffmpeg version used by losslesscut (ffmpeg 6.0)

ffmpeg -hide_banner -ss '0.00000' -i 'test.wav' -t '14.35732' -af 'silencedetect=noise=-60dB:duration=2.0' -vn -f null -

The response confirms that it detects the wrong silence_end:

[silencedetect @ 0x600003bf8000] silence_start: 10.4954   
[silencedetect @ 0x600003bf8000] silence_end: 14.3573 | silence_duration: 3.86195

If I run it in ffmpeg version 7.0.2 it returns the correct silence_end:

[silencedetect @ 0x6000033d4780] silence_start: 10.495374
[silencedetect @ 0x6000033d4780] silence_end: 14.357324 | silence_duration: 3.86195

So I think this problem will be auto-fixed once losslesscut upgrades its ffmpeg version to 7. #2255

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants