TaherZiad/montage-crew

자동 컷 - 측정 기반 침묵 및 데드 웨이트 트리밍

원칙

1. 장면/자막을 만들기 전에 컷을 수행하십시오. 컷 이후에 수행하면 모든 타임스탬프(자막, 줌, 효과음)가 어긋납니다. 이 단계의 결과는 assets/<source>.cut.mp4 + assets/transcript.cut.json이며, 이후 모든 단계는 컷 버전을 사용합니다.
2. 브리프에서 autoCut을 활성화하면 컷은 필수입니다. 선택 사항이 아닙니다. 컷할 내용이 없으면, 보고서에 구체적인 이유(영상이 이미 충분히 빡빡함)를 명시해야 합니다.
3. 임계값은 서버에 있으며, 당신의 머리 속에 있지 않습니다. silencedetect를 직접 실행하거나 dB 임계값을 직감으로 선택하지 마십시오. 두 가지 측정된 사실이 이 워크플로를 무효화했습니다:
   • 올바른 임계값은 파일의 속성(property)이지 상수가 아닙니다. 실제 파일에서 -40dB는 0개의 침묵을 찾았고, -30dB는 13개, -25dB는 21개를 찾았습니다. 하드코딩된 숫자는 쓸모가 없거나 음성을 잘라냅니다.
   • 음량(loudness)만으로는 '멈춤'과 '조용히 말하기'를 구별할 수 없습니다. 측정된 소스 파일에서 silencedetect -30dB는 48.6초의 '침묵'을 보고했지만, 실제 단어 사이의 간격은 18.2초에 불과했고 나머지 30.4초는 단어 내부(음절 구분, 무성 베트남어 종성 c/t/p/ch)에 있었습니다. 소리 수준만으로 컷하면 음성을 삼킵니다. 서버는 측정(autoTrim.ts)과 후보 생성(deadWeight.ts)을 수행합니다. 당신은 검토를 수행합니다. 이러한 분리가 핵심입니다.
4. 컷되는 데드 웨이트에는 두 가지 종류가 있습니다: 침묵(기계 측정, 대본에 의해 보호됨)과 콘텐츠 데드 웨이트(필러, 더듬거림, 재구성된 테이크 - 서버가 제안하고 당신이 승인하며, 반복 POINT는 당신만이 찾을 수 있습니다 - 3단계 참조).

0단계 - 전제 조건: 단어 타임스탬프가 있는 대본

전체 보호 장치는 이것에 의존합니다. 서버는 assets/transcript.raw.json을 먼저 찾고, 그다음 assets/transcript.json을 찾습니다. 이것이 없으면 분석은 여전히 실행되지만 guarded: false로 돌아오고, 데드 웨이트 목록은 비어 있으며, 숫자는 양방향으로 추측에 불과합니다(잘못된 컷을 통과시키고 좋은 컷을 실패시킬 수 있습니다). 먼저 대본을 생성하십시오. 보호되지 않은 베트남어 토킹 헤드를 절대 트리밍하지 마십시오.

1단계 - 분석 (무료, 반복 가능, 인코딩 없음)

POST http://localhost:6869/api/projects/<id>/auto-trim/analyze
body: {}                                   # 또는 { "source": "assets/face.mp4", "level": "tight" }

level은 natural | default | tight이며 기본값은 brief.autoCutLevel입니다. 응답:

• silence - durationSec, 선택된 thresholdDb + thresholdNote(해당 임계값이 선택된 이유), 측정된 noiseFloorDb, 컷될 silences, keepRanges, removedSec, 전체 sweep 테이블, 그리고 wordGuard(대본이 거부한 초 수).
• deadWeight - kind(filler | stutter | repeat-take | hesitation), start/end, text, confidence, reason, context를 포함하는 candidates[]; 또한 totalSec 및 byKind.
• guarded - 대본이 발견된 경우에만 true입니다. false이면 컷 전에 수정하십시오.

인코딩은 없으므로 원하는 만큼 자주 호출할 수 있습니다(217초 소스는 약 1초 만에 분석됩니다).

2단계 - 모든 후보 검토 (당신의 작업, 기계의 작업이 아님)

목록은 결정론적입니다: 동일한 대본, 동일한 후보, 동일한 신뢰도. 기계가 할 수 없는 것은 의미를 이해하는 것입니다. 하나씩 살펴보고 자신이 변호할 수 있는 후보만 유지하십시오:

• 낮은 신뢰도는 '아마 괜찮을 것'이 아니라 '먼저 문맥을 읽으라'는 의미입니다. 베트남어 필러는 거의 항상 실제 단어와 충돌합니다. đó, ấy, thế, mà, là는 필러 입자이면서 동시에 실제 지시사/접속사입니다.
• 연결 구문(hoặc là, tức là, bởi vì là, với lại là)은 함정입니다. 실제 대본에서 측정된 예: "…có thể là ok ứng dụng nó / Hoặc là / Tham khảo để tìm cách…"는 진정한 대안입니다. 이를 자르면 문장의 한 가지가 파괴됩니다. 그러나 "Còn trường hợp mà mọi người có thể nghe / Hoặc là / Còn trường hợp mà người AI không ứng dụng được…"는 중단된 문장이므로 제거해야 합니다. 표면 형태는 동일하며, 오직 의미만이 둘을 구분합니다. 이것이 바로 이들이 낮은 기본 신뢰도와 '문맥을 읽으라'는 이유와 함께 반환되는 이유입니다.
• repeat-take 후보: 승인하기 전에 나중 테이크가 실제로 더 완전한지 확인하십시오.
• hesitation 후보는 단어 사이의 순수한 침묵입니다. 일반적으로 안전하지만, 펀치라인 전 계획된 멈춤을 제거하는 것은 아닌지 확인하십시오.

자유롭게 거부하십시오. 필러 하나를 남기면 0.4초가 낭비됩니다. 실제 단어를 자르면 문장이 말이 안 되고 시청자가 즉시 알아차립니다.

3단계 - 반복 POINT (오직 당신만이 찾을 수 있습니다 - 필수)

어떤 탐지기도 이것을 잡아내지 못하며, 이것이 사용자들이 가장 불평하는 데드 웨이트입니다. 대본을 구어체로 읽고 의미적으로 분석하십시오:

1. 동일한 POINT를 말하는 문장 그룹화 - 단어가 일치할 필요는 없으며, 내용만 일치하면 됩니다. 화자는 종종 하나의 요점을 2-3번 반복합니다: 짧고 더듬거리는 첫 번째, 나중에 더 완전하게. 인접하지 않은 문장도 고려하십시오(요점 A를 말하고, 빈둥거리다가, 요점 A를 더 자세히 다시 말함).
2. 그룹당 정확히 하나의 버전 유지 - 가장 완전한 것:
   • 이전 짧은 버전, 이후 더 완전한 재진술 -> 이후 버전 유지, 이전 버전 제거.
   • 이후 문장이 단지 짧은 메아리("đúng vậy, như tôi nói…")일 경우 -> 이전 버전 유지, 메아리 제거.
   • 두 개의 동등한 버전 -> 더 매끄러운 전달(더듬거림이 적고 필러가 없는)을 유지.
3. 컷 후 흐름 확인: 유지된 텍스트를 처음부터 끝까지 다시 읽으십시오. 유지된 문장이 자신이 제거한 문장을 다시 참조("như vừa nói")하는 경우, 둘 다 유지하거나 역참조가 없는 버전을 선택하십시오.
4. 각 결정을 {start, end} 범위로 전환하고 승인된 후보와 함께 4단계로 보내십시오.
5. 컷 전에 테이블 생성(보고서에 포함): timestamp | 제거된 문장 | 이유 | 유지된 문장 - 사용자가 모든 결정을 검토할 수 있도록.

4단계 - 적용 (렌더 큐를 통해 진행됨)

POST http://localhost:6869/api/projects/<id>/auto-trim/apply
body: { "cutCandidates": [{ "start": 51.81, "end": 52.25 }, …] }   # 승인한 것만
-> 202 { job }

아무것도 승인하지 않았다면 빈 목록을 보내십시오 - 측정된 침묵은 여전히 제거됩니다. 그런 다음 GET /api/jobs/<jobId>를 폴링하여 작업이 완료될 때까지 기다리십시오. 작업:

1. 대본 보호 장치로 재분석하고, 침묵 범위를 승인된 범위와 병합합니다(중복 병합, 이중 계산 없음).
2. 단어 중간 지점을 삼키는 승인된 범위를 삭제합니다 - 검토에 대한 최종 안전망이며, 거부된 각 범위를 기록합니다. 로그에 거부된 범위는 실제 음성 위에 있는 것을 승인했음을 의미합니다. 해당 지점으로 돌아가서 다시 읽으십시오.
3. 하나의 ffmpeg 패스(trim/atrim + setpts/asetpts + concat)로 컷하고 assets/<stem>.cut.mp4를 작성합니다.
4. 모든 타임스탬프를 컷 타임라인에 다시 매핑 -> assets/transcript.cut.json.
5. 다시 매핑된 단어로 출력을 검증하고 assets/auto-trim-report.json을 작성합니다.

컷할 가치가 없는 경우, 작업은 의도적으로 .cut.mp4를 생성하지 않습니다(재인코딩된 동일한 복사본은 품질만 저하시킵니다). 보고서의 output은 null이며 소스를 계속 사용합니다.

5단계 - 보고서 읽기 (보고서를 읽을 때까지 작업이 완료된 것이 아님)

assets/auto-trim-report.json에는 다음이 포함됩니다: 컷 전/후 지속 시간, removed.silenceSec 대 removed.approvedSec, 선택된 임계값 및 이유, 거부된 후보, 그리고 verification.

• verdict: "pass" - 결과가 해당 수준의 프로필을 충족합니다.
• verdict: "fail" - 작업은 여전히 완료되었고 파일은 사용 가능하지만, 프로필을 충족하지 못했습니다. 로그에 명시적으로 표시됩니다. 더 많은 데드 웨이트를 승인(2/3단계)하고 apply를 다시 실행하거나, 최종 보고서에 수용하는 이유를 명시하십시오. 실패를 무시하면서 컷이 완료되었다고 보고하지 마십시오.

통과 기준은 더 이상 이전의 "침묵 > 0.8초 없음" 규칙이 아닙니다. 측정 결과 해당 규칙이 너무 느슨하다는 것이 밝혀졌습니다. 실제 파일이 이를 통과했지만, 0.45-0.67초의 13개 잔여 침묵(총 6.7초, 런타임의 4.2%)을 가지고 있었으며, 이는 명백히 지루하게 들립니다. 이제 프로필은 가장 긴 단일 침묵과 총 비율을 모두 제한합니다(default: 0.5초 / 3%).

6단계 - 모든 곳에서 컷 버전 사용

이제부터 자막, 키 레이아웃, 효과음 타이밍 및 줌은 assets/transcript.cut.json과 .cut.mp4를 읽습니다. QC 검사 dead-air는 조립된 비디오를 대본에 대해 다시 측정하고 brief.autoCut이 켜져 있고 데드 에어가 여전히 프로필을 초과하면 실패합니다. 이것은 백스톱이지, 계획이 아닙니다.

최종 보고서에는 다음이 포함되어야 합니다: 3단계의 컷 테이블, 제거된 초(침묵 대 승인된 데드 웨이트로 분할), 그리고 검증 결과. 숫자는 auto-trim-report.json에서 가져오십시오.

알려진 문제

• 컷 후 이전 대본 사용 -> 자막이 끝으로 갈수록 동기화에서 점점 더 벗어납니다. 항상 transcript.cut.json으로 전환하십시오.
• 침묵만 제거하고 반복 POINT를 무시하는 경우 - 사용자가 "데드 웨이트"라고 부르는 것은 대부분 3단계입니다.
• 소스 대신 렌더링된 드래프트를 컷하는 경우 -> 두 번째 인코딩으로 인해 품질이 저하됩니다. 항상 소스에서 컷하십시오(서버는 소스 덮어쓰기를 거부하고 기본 선택 시 이미 *.cut.*로 이름이 지정된 파일을 건너<0xEB><0x85>니다).
• 유일한 대본이 원시(raw) 대본인 상태에서 .cut.mp4를 분석하는 경우 -> 보호 장치가 잘못된 타임라인에 정렬됩니다. 소스 파일을 설명하는 대본과 일치시키십시오.
• 자체 리드 침묵이 있는 SFX/내레이션 파일 -> data-media-start를 사용하여 HyperFrames 내에서 트리밍하십시오(noti-tiktok-vn 스킬의 "SFX loudness and lead silence" 참조), 0.3초의 리드 침묵을 위해 오디오 파일을 재인코딩하지 마십시오.
• 페이드 없이 컷 세그먼트 연결 -> 모든 연결 지점에서 클릭음 발생. autoTrim.ts에서 수정되었습니다. 규칙은 아래에 있으며, 오디오를 컷하거나 연결하는 모든 새 코드에 적용됩니다.

오디오: 모든 컷 가장자리에서 30ms 페이드 (엄격한 규칙)

컷은 파형 중간에 이루어집니다. 한 세그먼트의 마지막 샘플과 다음 세그먼트의 첫 번째 샘플은 관련이 없으므로, 연결은 수직 단계(vertical step)이며, 단계는 클릭입니다. 원인은 인코더나 소스가 아니라 연결 자체이므로, 다운스트림의 모든 재인코딩에서도 존속됩니다.

얼마나 중요한지는 컷이 착지하는 위치에 따라 크게 다릅니다. 실제 278초 토킹 헤드에서 무손실로 측정되었으며, 페이드가 있는 경우와 없는 경우 동일한 컷을 비교했습니다(연결 지점에서 가장 큰 샘플 간 단계; 약 0.02 이상이면 들림):

연결 종류	페이드 전	페이드 후
침묵 트리밍, 40개 연결(balanced)	중앙값 0.0040, 최악 0.0113 - 들리지 않음	중앙값 0.0000
말하기 중간, 4개 연결(데드 웨이트 / 반복 POINT)	0.1195, 0.0744, 0.0232, 0.0064 - 4개 중 3개 들림	모두 ≤ 0.0008

참고로, 해당 파일에서 일반적인 말 중 가장 큰 단계는 0.06-0.13이었습니다. 따라서 말하기 중간 연결은 페이드 없이 콘텐츠 자체가 생성하는 것보다 더 큰 점프가 될 수 있는 반면, 침묵 연결은 들리지 않습니다.

첫 번째 행만 보고 페이드를 생략하지 마십시오. 단순 침묵 트리밍은 우연히 문제가 되지 않는 경우이며, 3단계(반복 POINT) 및 클립 추출은 말 중간을 직접 자르며, 이러한 연결에서 클릭이 발생합니다.

수정: 모든 세그먼트의 양쪽 가장자리를 30ms 동안 페이드 처리합니다. 단계를 없애기에 충분히 길고, 페이드로 인식되지 않을 정도로 충분히 짧습니다. apps/server/src/util.ts의 audioCutFade()를 사용하십시오. 필터를 직접 구현하지 마십시오.

[0:a]atrim=start=S:end=E,asetpts=PTS-STARTPTS,afade=t=in:st=0:d=0.030,afade=t=out:st=D-0.030:d=0.030[aN]

조용히 아무것도 하지 않게 만드는 세 가지:

• 순서. afade는 asetpts=PTS-STARTPTS 다음에 와야 합니다. afade는 스트림 자체 클록에서 st를 읽습니다. 원본 타임스탬프에서 st=0은 과거이므로 페이드인이 실행되지 않습니다.
• 길이. D는 세그먼트 지속 시간이므로 페이드 아웃 시작은 D - 0.030입니다. 페이드를 D/2로 고정(clamp)하거나, 짧은 세그먼트에서 두 페이드가 겹쳐서 세그먼트를 삼켜버립니다.
• 클립 추출, 단순 연결이 아님. 더 긴 비디오에서 잘라낸 클립은 아무것도 연결되지 않더라도 동일한 두 개의 날 가장자리를 가지고 있습니다. reframe.ts는 -af를 통해 이를 페이드 처리합니다.

직접 측정할 때의 한 가지 참고 사항: 두 개의 AAC 인코딩을 비교하지 마십시오. 재인코딩은 모든 곳에서 샘플을 교란하여 40개의 실제 연결을 294개의 스퓨리어스 차이 영역 속에 묻고 두 파일 사이에 54ms 오프셋을 생성했습니다. 대신 두 변형을 pcm_s16le로 직접 렌더링하십시오. 그러면 두 파일이 샘플 정렬되고 연결이 누적 세그먼트 길이에 정확히 위치합니다.