InferNews

CrisperWhisper 把語音逐字稿變成可控制輸出

Share to X
Repository image for nyrahealth/CrisperWhisper

做會議紀錄、訪談整理或臨床語音分析時，最大落差往往唔係辨識到幾多字，而係系統究竟寫出「講咗乜」定「本來想表達乜」。CrisperWhisper 屬於開源語音辨識模型項目，核心價值係將 verbatim 同 intended 兩種轉錄模式變成可明確控制的輸出，令逐字稿唔再受訓練資料風格左右。

呢個取向同一般 speech-to-text 系統好唔同。常見做法會不一致地刪走 filler、重複、停頓同 cut-off，CrisperWhisper 2.0 就刻意保留呢啲語音細節，或者按需要輸出整理後版本；同一段錄音可以得出兩份用途完全不同嘅文本。對做 TTS 資料整理、醫療或研究訪談分析、需要精準字幕時間碼嘅團隊，呢種分流比單純追求可讀性更有用。

項目另一個關鍵位係時間對齊同長音訊處理。它提供 word-level timings，讀稿語音平均邊界誤差約 30 ms，對話語音約 41 ms；長音訊則用 conditional continuation 避免一般分段轉錄常見嘅重複漏字。README 亦提到推理端基於 CTranslate2，配合 speculative decoding，同時減輕 Whisper 常見 looping-hallucination 問題，方向明顯係朝住 production inference。

  • verbatim 與 intended 兩種模式分開控制，適合同一錄音對應不同工作流
  • 支援 multilingual，覆蓋多數 Whisper 支援語言
  • 可用 Verbatimize 依據音訊加乾淨文本補回真實語氣詞與口誤
  • 長音訊轉錄著重連續性，減少 chunk 邊界造成嘅錯漏
  • Nyra Verbatim Speech Benchmark 以 disfluency F1 等指標衡量保真能力

安裝與部署方向相對清晰：模型可經 PyPI、Hugging Face 同文件使用，推理路線圍繞 CTranslate2 runtime，而唔係只停留喺研究展示。要留意嘅取捨亦好直接，當你要的是可讀、可發布文本，intended 模式更合適；當你要保留猶豫、重複、笑聲同語音事件，verbatim 模式先真正發揮價值。呢個項目唔係單靠更高 WER 成績去吸引人，而係重新界定逐字稿應否忠於說話表面形式，並且用 benchmark 將呢件事量化。

項目主頁 · GitHub · 模型

Categories: 開源, NVIDIA, 文字轉語音, Medical醫學, 模型, 語音, Dataset 數據集

FunASR 工業級語音辨識：支援廣東話

Share to X
Repository image for modelscope/FunASR

如果你做過語音相關項目，大概率遇過呢種情況：開源模型散落喺唔同倉庫、部署方式各異、要接入 Agent 仲要自己寫 WebSocket 中間層。FunASR 就係針對呢類工程痛點嘅工業級語音識別工具包，屬於開源框架，由阿里達摩院維護，提供統一 Python 接口，將 ASR、VAD、標點恢復、說話人分離、情感偵測同音訊事件辨識串成一條流水線。

旗艦模型 Fun-ASR-Nano 係基於 LLM 嘅解碼架構，覆蓋中、英、日三語以及中文方言群組；針對 31 種語言嘅場景可以用 Fun-ASR-MLT-Nano-2512；鍾意多語言又有 LLM 解碼能力嘅，亦有 Qwen3-ASR（52 種語言、0.6B/1.7B 參數）。如果想要更輕量、非自迴歸嘅選擇，Paraformer 同 SenseVoice 仍係穩陣起點，前者適合生產線串流，後者額外送情感同音訊事件標籤。

funasr-server 一行指令就可以拉起 OpenAI 相容嘅轉寫 API，本地聽返 localhost:8000，配合 vLLM 仲可以做到 2-3 倍 LLM 解碼加速同 tensor parallel 批次推理。Agent 整合係另一個重點：MCP Server 可以直接接入 Claude 或 Cursor，OpenAI API 接口又同 LangChain、Dify、AutoGen 無縫對齊。最近幾個版本（v1.3.18 至 v1.3.22）就專門執緊 SRT/字幕分段、長時 WebSocket 連線、verbose_json 回傳呢啲工程細節。

要留意嘅取捨係：Fun-ASR-Nano 需要 GPU；新環境第一次 import funasr 已唔再強行依賴 PyTorch，但用 AutoModel 仍然要先裝 torch。FunASR 比較適合需要私有語音 API、字幕生成、長會議轉寫、或想將語音能力塞入 Agent 工作流嘅團隊開發者。

重點摘要：

  • 統一 Python 接口整合 ASR、VAD、標點、說話人分離、情感偵測
  • Fun-ASR-Nano 旗艦模型支援 31 種語言及中文方言，Fun-ASR-MLT-Nano 覆蓋更廣
  • funasr-server 提供 OpenAI 相容 API，搭配 vLLM 可達 2-3 倍加速
  • 內建 MCP Server 支援 Claude/Cursor，亦可接入 LangChain、Dify、AutoGen
  • 近期版本持續優化字幕分段、WebSocket 長連線、verbose_json 回傳等工程細節

以下是其對粵語支持的詳細信息：

  • UniASR模型：這是一個專為粵語設計的語音識別模型，能夠處理簡體中文的粵語語音識別任務。
  • ITN模型：用於對粵語語音識別結果進行擬文本正則化後處理，以提高識別結果的準確性。
  • VAD模型：語音端點檢查模型，用於檢測長語音片段中有效語音的起止時間點，這對於粵語方言的語音識別同樣重要。
  • 訓練語料：為了提高模型的準確性和適用性，通常會使用大量的粵語語料進行訓練，以便模型能夠更好地理解和識別粵語中的特有詞彙和表達方式。
  • 離線功能：Funasr提供了離線語音識別模型，這意味著即使在沒有網絡連接的情況下，也能夠進行粵語語音識別。

項目主頁 · GitHub

Categories: 開源, Qwen, NVIDIA, Agentic, API, MCP, IDE, LangChain, Python, 語音, Dataset 數據集

Wan Streamer v0.3：讓 AI 學懂「世界不變，只有事件在流動」

Share to X
A robot navigates a suburban neighborhood and drives a car through a sequence of events

玩過 AI 影片對話工具的人都會發現一個矛盾：模型可以跟你聊天，但一旦想做動作，畫面就容易卡頓、失憶，甚至換了一張臉。Wan Streamer v0.3 想解決的就是這個問題——它把影片分成兩件事來學，一件是「世界設定」（場景、角色、畫風、聲音這些要長期保持一致的東西），另一件是「事件流」（說話、動作、鏡頭移動、環境變化這些隨時間發生的事）。

這個拆法聽起來抽象，但對使用者來說，最直接的差別就是角色終於可以做自然語言描述的動作了。你打開鏡頭，模型會一邊跟你說話，一邊伸手拿起眼前的物件、轉向聲音來源、或者露出驚訝的表情，而且動作和對嘴的時序是學出來的，不是後製對齊的。延遲仍然維持在約 200 毫秒，解析度 640×368、幀率 25fps，即時互動不會被打斷。

從工作流角度看，這個版本最大的價值是把普通影片變成訓練素材：先建立世界，再沿時間軸學接下來會發生什麼。同一套能力日後可以遷移到漫遊探索、機器人控制等場景，而這次發佈聚焦在即時音視頻對話。

重點摘要：

  • 拆解式學習：將「持續世界」與「事件流」分開建模，避免長對話中場景漂移
  • 自由動作描述：支援用自然語言寫出動作（如拿取物件、轉向、變換姿勢），並與對話同步渲染
  • 即時互動規格：640×368、25fps、約 200ms 模型側延遲，支援全雙工音視頻
  • 普通影片即訓練素材：不需特殊標註，現成影片就能用於學習時間軸上的因果事件
  • 可遷移架構：同一套預訓練能力可延伸至具身導航、漫遊等場景

對於做數位人、虛擬主播、互動敘事或即時陪聊的團隊，這個方向值得留意；對於只是想試試看的個人，現有 demo 已經足夠展示「角色真的在過日子，而不只是在回話」的差異。

項目主頁

Categories: Video, Audio, 多模態模型, 模型訓練, 語音, Robotic, 世界模型, Skill 技能

MultiRef-Compass：多模態影片不再各自為政

Share to X
MultiRef-Compass overview

同一段生成影片，畫面可能順眼、聲畫卻唔對位；角色外觀接近參考圖，指令跟從又未必準。MultiRef-Compass 抓住呢種常見落差，定位成一個開源評測工具包，處理 multi-reference multimodal video generation 的比較問題，重點唔係逐條片人手睇，而係用可重現的方法把不同模型放到同一把尺上量度。

它的取向相當明確：偏向研究比較，而唔係臨時檢查作品。項目用固定的 CSV 輸入欄位，接收文字、視覺參考、音訊參考同生成影片，再輸出 per_sample.csv、model_summary.csv、ranking.md 同 details.json。這種設計的好處，是團隊可以用同一批樣本反覆測不同模型；代價是流程較講究資料整理，較適合已有實驗管線的人。

跟只看單一分數的做法相比，MultiRef-Compass 把結果拆成四組共 14 個公開指標，包括 Basic Quality、Entity Fidelity、Audio-Video Consistency 同 Instruction Following。它同時混合 classical media-analysis pipelines、learned quality models、speaker embeddings，以及 multimodal language model judges，所以看到的不只是整體高低，仲會知道問題出在 anatomy、reference fidelity、voice timbre similarity，定係 temporal order。

  • 用統一 schema 比較不同影片生成模型，較容易做橫向排名
  • 保留 sample-level diagnosis，同時支援 model-level ranking
  • 支援 text、visual-reference、audio-reference 三種條件一齊評測
  • 著重公開 metric taxonomy，同類研究較易重現結果

現有資訊未見到完整安裝細節，但理解方式已很清楚：先準備符合欄位要求的 CSV manifest，再按指標群組跑評測後端。受益最大的，會是做多模態影片生成、聲畫對齊、角色一致性與指令跟從研究的團隊。相關能力圍繞 Visual Quality、Audio Quality、Entity Fidelity、Speech-Lip Synchronization、Voice Timbre Similarity 等指標展開；它未必幫你直接提升模型質素，卻能先把模型到底差在哪一環講清楚。

GitHub · 模型

Categories: 開源, Video, Audio, Embedding, 多模態模型, 視頻模型, 語音

LightMem-Ego：AI 眼鏡及手機的日常記憶系統

Share to X
LightMem-Ego Logo

LightMem-Ego 由 Zhejiang University、South China University of Technology、Central China Normal University 與 Lenovo Group Limited 共同開發。它瞄準的是手機與 AI 眼鏡長時間接收影像、聲音後，怎樣把零散片段變成可追問的日常記憶，屬於端到端 streaming multimodal memory system。

現有多模態助理多數擅長回答當下畫面或單次對話，但要回想剛才誰講過甚麼、物件放在哪裏、一天內發生過甚麼，就需要把連續經驗累積、整理和檢索。LightMem-Ego 的做法是把第一身 visual-audio streams 對齊到同一條時間線，再分成 Current memory、Short-term memory 和 Long-term memory，查詢時按問題動態路由到合適記憶層，並用 timestamped multimodal evidence 支撐答案。

  • 工作流定位：連接 Rokid AI Glass Android app、browser frontend 和 online backend service。
  • 主要用途：object finding、conversation recall、life summarization、routine discovery 和 hands-free wearable assistance。
  • 核心取捨：不是只追求單次多模態理解，而是把輕量、持續累積和可檢索記憶放在中心。
  • 部署理解： Quick Start 與 glasses + web deployment，但提供資料未列出完整安裝指令或模型配置細節。

對可穿戴裝置開發者、個人助理產品團隊來說，這個項目的價值在於它把擷取、時間線對齊、記憶分層和問答串成一條較完整的流程。它也較適合需要測試「長時間生活脈絡」的場景，而不是只做單張圖片問答或短語音轉錄。

性能與評估資料在提供內容中仍然有限，未見具體 benchmark 數字可引用。相關模型資料只提到 multimodal large language models 的背景，包括 OpenAI 與 Gemini；未明確指定 LightMem-Ego 後端必須使用哪一個固定模型。

GitHub · Paper

Categories: 開源, Gemini, OpenAI, Agentic, Audio, 多模態模型, 語音, 中國, Dataset 數據集, 框架

phone-metrics：少量標註做語音音素切分

Share to X
Repository image for stephenmac7/phone-metrics

做語音分析時，最麻煩的不只是辨認講了甚麼音，還要知道每個 phone 在哪一刻開始、哪一刻結束。phone-metrics 對應的是一個語音研究項目，重點放在 phone segmentation 與 phone recognition 一起處理，目標是減少標註成本，同時保住辨識效果。

在語音處理中，有兩個核心任務： 音素分割（Phone Segmentation）：找出一段話中，每個發音與下一個發音之間的「時間邊界」（例如在哪一毫秒從 [s] 轉變到 [z]）。音素識別（Phone Recognition）：認出這個發音到底是什麼音（類似音標）。傳統的做法： 這兩個任務通常是分開用不同的 AI 模型處理。而且，要訓練這種模型需要專家耗費大量時間（標註 1 小時的語音往往需要專家花 40 到 100 小時），成本極高。

現有做法常把 segmentation 和 recognition 分開建模，但這項工作認為兩者其實共享同一套語音結構，分開做會浪費訊號。作者改為從 self-supervised speech model（S3M）的表示中抽出 phonological feature activations，並用 SPAM（S3M-based Phonological Activation Mapping）把每個時間 frame 轉成像 voicing、nasality 這類語音特徵，再接兩個輕量、毋須 gradient descent 的 prediction heads，分別負責切分與辨識。

這個取向最值得留意的地方，是它對資料量要求很低。資料指出，少於一分鐘、而且帶 time-aligned phonetic transcriptions 的標註已可運作；同時它還能處理訓練期間未見過的 phones，對低資源語言、zero-shot phonetic analysis，甚至做跨語言比較都幾有吸引力。

  • 把 phone segmentation 與 phone recognition 聯合處理，唔再拆成兩個獨立流程
  • 依賴 self-supervised speech model（S3M）內部已有的語音結構，而唔係完全重新學起
  • SPAM 先把 frame 映射成 phonological activations，再交由兩個輕量 prediction heads 輸出結果
  • 標註需求非常低，少量 time-aligned phonetic transcriptions 已可測試方法價值
  • 已報稱在多個資料集上達到 SOTA phone segmentation，並取得穩健的 recognition 表現

部署和驗證這類項目時，較合理的理解方式不是把它當成即裝即用產品，而是研究型 pipeline：先準備語音資料與對齊好的音素標註，再接入 S3M 表示，之後檢查 segmentation 邊界與 recognition 輸出。它較適合語音研究團隊、低資源語言項目，或者想用更少標註測試新語音單位分析方法的人；若你要的是完整語音轉文字應用，它就不是直接替代 ASR 的那一路。

項目主頁 · GitHub · Paper

Categories: 開源, DeepSeek, Medical醫學, 影像處理, 語音, Dataset 數據集

audio.cpp-webui：本地音訊 AI 一站式介面

Share to X
Parity test flow

要同一部電腦處理 TTS、voice cloning、ASR 同音訊增強，最大阻力往往唔係模型本身，而係部署鏈太散。audio.cpp-webui 把這件事收斂成一個偏向本地部署的音訊推理框架＋WebUI 工具：核心沿用上游 0xShug0/audio.cpp，以 C++ 配合 ggml 執行，這個分支再補上完整任務介面同較友善的 Windows 啟動方式。

它的定位幾清楚：唔係只做單一模型展示，而係想用同一套 runtime 接住多類音訊工作流。你會見到它涵蓋 TTS、voice conversion、ASR、diarization、VAD、source separation，連 denoise、resampling、STFT/ISTFT 都內建，較接近「把多個音訊 AI 能力放入同一個本地工作台」，而唔係逐個 Python 項目分開跑。

本地语音 AI 终于统一了！ 实时对话、声音克隆、AI 翻唱8G 显存全跑通｜audio.cpp｜整合包

跟常見 Python 參考路徑相比，這個項目的取向是用原生執行環境換取更穩定的部署體驗同速度，代價是功能節奏仍然受上游整合進度影響，而且部分高階流程像 JSON pipeline 仍屬 experimental。效能數字是它最值得留意的一環：多條 TTS 路徑在 CUDA 上可比 Python reference paths 快 1.8x 至 5.0x，端到端延遲可降低 45% 至 80%；README 亦列出 VibeVoice 1.5B 能在 18.2 分鐘生成 93.9 分鐘 podcast。

  • 可用 webui.bat 啟動 Gradio WebUI，本地網址是 http://127.0.0.1:7860
  • 支援按需載入模型、模型切換、下載模型、上傳或錄製 reference voice
  • 內建進階參數控制，同頁可見執行狀態與錯誤訊息
  • 較適合想在 Windows 或本地 CUDA 環境整合多種音訊任務的人員與小團隊

相關模型與路線目前集中在多種本地音訊模型家族，文中點名 VibeVoice 1.5B，整體則圍繞現代 audio models 的統一推理。對內容製作、語音原型、內部工具驗證，甚至要把多步驟流程包成固定操作的人來說，它補上的並非新奇功能，而是把本來零散的模型執行方式整理成較可重用、較易維護的本地項目基礎。

GitHub

Categories: 開源, NVIDIA, 文字轉語音, Audio, 工具, Clone, Python, 語音

MOSS-Transcribe-Diarize：多人長音訊一站式轉錄

Share to X
OpenMOSS Logo

會議、訪談、podcast 呢類長音訊，最麻煩唔係單純變成文字，而係要一路保留時間碼、一路分清楚邊個講緊。MOSS-Transcribe-Diarize 屬於音訊理解模型，集中處理長篇多人語音轉錄同 speaker diarization，輸出已經連同時間戳同講者標籤，例如 [S01]、[S02]，比起先做 ASR 再另外接 diarization，流程更完整。

呢個項目的取向相當鮮明：它唔係把幾個系統串連，而係用 end-to-end 方式一次過完成 transcription、speaker diarization、timestamps，連 acoustic event awareness 都納入同一模型。好處係輸出格式更統一，段落對位較自然；代價則是你要接受它的整體輸出設計，而唔係自由替換其中一段模組。

目前公開的是 MOSS-Transcribe-Diarize 0.9B，定位為開源 SOTA 模型；另有更強的 MOSS-Transcribe-Diarize Pro，但會以 API 形式提供。部署路線算清楚，倉庫已列出 Python 用法、自訂 prompt 與 hotwords、用 vLLM 或 SGLang Omni 提供服務，亦有 Subtitle Web App，表示它不只適合研究測試，也可朝內容整理、字幕製作同語音工作流整合發展。

  • 把 ASR 與 speaker diarization 合併，減少多階段對齊誤差
  • 直接輸出帶時間戳的文字流，適合字幕、會議紀錄、訪談整理
  • 支援長篇、多講者、較混亂的真實錄音場景
  • 0.9B 已開源，Pro 版本主打更高整體表現並將經 API 提供

受惠最大的會係做會議紀錄、媒體轉寫、客服通話分析同教育內容整理的團隊，因為他們最在意的往往不是單句辨識，而是整段內容可否穩定交付。現有資料提到它屬於 SOTA 等級，也有獨立 Evaluation 章節，但未見完整數字細節一併列出；能夠確認的是，相關模型目前包括 MOSS-Transcribe-Diarize 0.9B 與 MOSS-Transcribe-Diarize Pro，前者著重開源可用性，後者走更高性能與 API 存取路線。

GitHub · 模型

Categories: 開源, API, Python, 模型, 語音

Vidu S1 把即時互動影片拉近一步

Share to X
Vidu S1 Experience Preview

比起先寫好提示詞再等片段輸出，Vidu S1更接近一種可對話的視頻模型：你一邊講，數碼角色一邊跟住反應，處理的是「影片生成能否即時被人打斷、改向、持續延長」這個卡位。項目把重心放在 voice-controlled digital characters，而不是一次過產出完整短片，定位很清楚是互動內容而非傳統文生影片。

現有做法多數仍是 prompt-driven、片段式生成，用戶先提交指令，再等待固定長度輸出；作者主張這種範式難以支援 live interaction。Vidu S1改用 real-time speech control 與 infinite-length real-time interactive generation，讓角色在生成途中持續接受 spoken instructions，方向上更接近直播角色、虛擬主播和即時陪伴互動，而不是 cinematic clip 製作。

  • 支援以語音即時控制角色動作，重點在連續互動而非單次出片
  • 可自訂角色形象與 voice tones，涵蓋真人、二次元、寵物等 avatar
  • 官方資料提到 540p、最高 42 FPS，並可在 consumer GPUs 運行
  • 除了網頁體驗，也提供 API 文件，較適合接入互動產品流程

現有公開資訊較偏向服務化體驗：可先在 Vidu Stream 網頁建立角色、選擇或 clone 聲線，再開啟麥克風與鏡頭進行 live call；團隊要接入自家產品，則更可能經 API 而非直接本地完整重建。GitHub 儲存庫目前公開了論文、說明文件與入口，但未見完整本地訓練或推理流程，較像展示能力與提供接入方式的研究／產品型開源項目。

取捨也很明顯：它強調流暢、低延遲、可長時間互動，代表優先次序未必是最高解析度或最複雜鏡頭語言。受益最大的會是做虛擬主播、互動陪伴、角色扮演、品牌數字人和即時內容演示的團隊；要做電影感分鏡、長敘事剪輯或高度後期控制，現階段未必是它最強的一面。相關模型則包括 Vidu S1 本身，以及同一服務脈絡下的 Vidu Stream 互動入口。

項目主頁 · GitHub · Paper

Categories: 開源, API, Clone, 多模態模型, 數字人, 視覺模型, 視頻模型, 語音, 清華大學, Dataset 數據集

speaker_disentangled_hubert：用 HuBERT 重新做好音節切分

Share to X
Repository image for ryota-komatsu/speaker_disentangled_hubert

做語音 tokenization，最麻煩的情況往往不是音節邊界找不到，而是模型把講者特徵一併學進去，最後分出來的 token 混雜了聲線而不是語言內容。speaker_disentangled_hubert 屬於語音模型項目，核心工作是把原始語音整理成較純淨的 syllabic token，讓後續的 speech language model 更容易學到句法與語意。

現有做法多數沿用 pretrained HuBERT 的 teacher-student distillation，再用 utterance-level cross-entropy 目標去組織 frame 表徵；作者認為這種 fixed 範式會令學生模型偏向預測 speaker identity。這個項目改用 Speaker-Disentangled Chunk-Wise Regression for Syllabic Tokenization，在 fixed-length chunks 內，將加入 speaker 擾動的 student representations 拉回乾淨的 teacher targets，重點不是再加更多標籤，而是直接削弱講者資訊對音節切分的干擾。

從結果來看，它的取向相當明確：寧願把訓練設計做得更細，也要換取更乾淨的 syllabic segments。論文指出，這套方法在 syllable boundary detection 與 syllabic segment clustering 都做到 state-of-the-art；再往下接 speech language model，基於這批 syllabic tokens 的模型，對比 phone-level SpiRit-LM，在 syntactic and semantic understanding 取得 7% relative improvement。對研究語音表示學習、低資源語音建模，或者想把離散語音單位接到語言模型的人，這個方向幾有參考價值。

  • 針對 HuBERT teacher-student distillation 容易混入 speaker identity 的問題
  • 用 chunk-wise regression 取代單純 utterance-level cross-entropy 訓練邏輯
  • 任務焦點包括 syllable boundary detection 與 syllabic segment clustering
  • 相關脈絡涵蓋 pretrained HuBERT、speech language model，以及 phone-level SpiRit-LM

測試與理解方式亦算直接：項目提供 Paper、Code、Model 與網頁上的 resynthesis samples、syllable segmentation 示例，先聽重建語音，再看音節分段，已經可以判斷 tokenization 有沒有保住語言結構。現有資訊未完整列出部署流程與安裝細節，所以較適合作為研究型項目閱讀、重現與比較；使用時也要留意，它的驗證主要建基於 LibriSpeech，跨語者以外的語種、錄音條件與資料分佈，仍然值得再做額外確認。

項目主頁 · GitHub · Paper

Categories: 開源, 語音, Dataset 數據集
Page 1 of 5
1 2 3 … 5