sentence_info text drifts away from its timestamps/speakers: Chinese VAD chunks are joined without a space before timestamp_sentence splits on spaces
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- audio-video-rtc, backend
Hướng nghiên cứu
Bắt đầu với _join_vad_texts trong funasr/auto/auto_model.py và timestamp_sentence trong funasr/utils/timestamp_tools.py; theo dõi cách inference_with_vad cung cấp văn bản và dấu thời gian cho bộ tách câu. Tái hiện vấn đề với hai đoạn tiếng Trung trong issue và kiểm tra xem văn bản của mỗi câu có tiếp tục khớp với dấu thời gian và người nói tương ứng hay không, đồng thời dấu câu vẫn chính xác.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
With vad_model + punc_model (+ spk_model), the text of each sentence_info entry is shifted relative to its start/end/timestamp/spk. The shift grows by one unit at every VAD chunk boundary where two Chinese chunks meet, so on long audio the sentence text ends up far ahead of the time range and speaker it is attached to. The top-level text (punctuated) is correct; only sentence_info[*].text is wrong.
Version
- funasr 1.4.16 (same code in 1.4.17 and current main)
AutoModel(model="paraformer-zh", vad_model="fsmn-vad", punc_model="ct-punc", spk_model="cam++"), Python 3.12, macOS, CPU
Minimal reproduction (no audio needed)
from funasr.auto.auto_model import _join_vad_texts
from funasr.utils.timestamp_tools import timestamp_sentence
chunks = ["今 天 天 气 很 好", "我 们 去 公 园 吧"] # two VAD chunks
punc_input_text = _join_vad_texts(chunks)
print(repr(punc_input_text)) # '今 天 天 气 很 好我 们 去 公 园 吧' ("好我" fused)
timestamps = [[i * 200, i * 200 + 200] for i in range(12)]
punc = [1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 3] # "," after 好, "。" after 吧
print(len(punc_input_text.split()), "text units vs", len(timestamps), "timestamps")
for s in timestamp_sentence(punc, timestamps, punc_input_text):
print(s["text"], s["start"], s["end"])
Output:
11 text units vs 12 timestamps
今天天气很好我, 0 1200
们去公园吧。 1200 2400
Expected 今天天气很好, / 我们去公园吧。.
Real-world impact
On a 19.5-minute Mandarin recording: 5299 timestamps and 5299 punctuation ids, but punc_input_text.split() yields only 5082 units (217 fused boundaries). Sentence text drifts up to ~217 characters (~50 s of speech) ahead of its timestamps, so:
- sentences are cut 1–N characters off (e.g.
然,/后用于…) - since speakers are distributed by time, text is attributed to the wrong speaker, often switching speaker mid-sentence
Cause
In AutoModel.inference_with_vad, punc_input_text = _join_vad_texts(...) intentionally joins Chinese chunks without a space (fine for the punctuation model, whose tokenizer splits CJK into characters, so punc_array length still matches). But the same string is then used as timestamp_text, and timestamp_sentence pairs units with timestamps via text_postprocessed.split(). The fused boundary units shift every following unit. The existing check punc_length != len(sentence_timestamps) doesn't catch it because the number of text units is never compared.
Suggested fix
Use a space-joined version of the chunk texts for timestamp_text (or have timestamp_sentence consume one unit per timestamp), and/or assert that the number of text units equals the number of timestamps.
Workaround we use for now: call generate(..., return_raw_text=True) and rebuild each sentence's text by taking len(sentence["timestamp"]) units from result["raw_text"].split() in order, keeping the trailing punctuation from sentence["text"]. With that, sentence boundaries and speaker turns line up correctly.
- Ngôn ngữ chính
- Python
- Star
- 20.9k
- Fork
- 2.1k
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 46
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelscope/FunASR
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
modelscope/FunASR#3796 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`SentencepiecesTokenizer.ids2tokens` ignores `token_list` - root cause of the paraformer-en gibberish in #3040Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
modelscope/FunASR#3780 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
modelscope/FunASR#3762 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug: blank lines in wav.scp / jsonl file lists crash prepare_data_iterator (IndexError / JSONDecodeError)Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởneeds feedback
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
modelscope/FunASR#3757 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
modelscope/FunASR#3730 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của modelscope/FunASR
Issue tương tự
-
DBFS append mode silently overwrites existing filesCó thể đã có người làm @IlyaKhalafi đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
fsspec/filesystem_spec#2429 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Retrieval rerank fallback statistics stay zero after provider failureCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
volcengine/OpenViking#7014 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
fedora-copr/copr#4600 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
ansys/pydpf-core#3620 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày