现在的名称应该既有主题又不啰嗦
这样的搜索命中率会高一些
花了3天时间
## 2026-03-19: 修复音频加载除零错误 + 输入目录缓存功能
### 问题 1: 音频加载除零错误
后台日志出现 `加载失败: division by zero`，某些音频文件加载时采样率为 0 或 None。
### 解决方案 1
在音频加载时添加采样率有效性检查：
**修改的文件:**
- `python/api_server.py:1299` - `load_audio_file()` 添加 `sr` 检查
- `python/utils/sync_json_db.py:482` - 添加 `sr` 检查并优雅降级
- `python/main.py:431` - `preprocess_audio()` 添加 `sample_rate` 检查
**代码示例:**
```python
if sr == 0 or sr is None:
return None, 0, 0, "无效的采样率(0)"
```
### 问题 2: 输入目录无法缓存
用户希望输入目录在退出程序后自动保存，下次打开时自动恢复。
### 解决方案 2
实现输入目录本地缓存功能：
**修改的文件:**
- `tauri/src/stores/app.js:72` - 更新 `saveConfig()` 支持同时保存输入/输出目录
- `tauri/src/views/Batch.vue`:
- `addInputDir()` - 添加目录后自动保存
- `removeInputDir()` - 删除目录后自动保存
- `clearInputDirs()` - 清空目录后自动保存
- `appendInputDir()` - 运行时追加目录后自动保存
- `selectOutputDir()` - 选择输出目录时同时保存输入目录
- `onMounted()` - 启动时自动加载缓存的输入目录
**Bug 修复:**
1. `appendInputDir()` 运行时追加目录未保存缓存
2. 空输出目录会覆盖已有配置
---
## 2026-03-18: 移除Ollama依赖，优化文件名和标签生成
### 问题
1. 本地无Ollama服务，但代码依赖Ollama API调用
2. `filename` 字段被LLM输出污染（如"根据提供的信息..."、"翻译结果如下..."等）
3. 文件名和标签中出现禁用词（未分类、素材、音效等无意义词汇）
### 解决方案
1. **统一使用本地GGUF模型** (qwen2.5-7b-instruct)
- 移除所有Ollama API调用
- 使用 `llama-cpp-python` 直接加载本地模型
2. **禁用词过滤（双重机制）**
- LLM Prompt中明确禁止输出禁用词
- 代码强制过滤作为保底
3. **文件名生成优化**
- 最大长度50字符
- 结尾清理中文标点
- 优先级：LLM生成 → tags_cn组合 → model_keywords → 分类名
4. **禁用词列表**
```python
FORBIDDEN_WORDS = {
"未分类", "其他", "人工审核", "素材", "音效", "声音", "音频",
"专业", "通用", "未知", "待处理", "待审核", "综合",
"unknown", "other", "uncategorized", "misc", "audio", "sound", "effect", "sfx"
}
```
### 修改的文件
- `python/main.py`: 移除Ollama参数，改用本地LLM，新增 `_filter_forbidden_tags`
- `python/classifier_v2.py`: 新增禁用词常量，重构 `_optimize_filename_with_llm`，新增验证函数
- `python/utils/tag_generator.py`: `generate_tags_with_ollama` 改为 `generate_tags_with_local_llm`
- `python/config.py`: 注释掉Ollama配置
### 关键代码位置
- `classifier_v2.py:35-50`: 禁用词和污染词常量
- `classifier_v2.py:560-680`: LLM文件名生成和验证
- `classifier_v2.py:682-760`: 文件名生成主逻辑
- `main.py:1235-1347`: 标签生成（使用本地LLM）
## 2026-03-16: 修复大量文件扫描进度卡住问题
### 问题
点击"开始分类"时，如果目录文件数量很大（如10万+），扫描阶段会卡住不动，界面长时间显示"正在扫描文件..."但没有进度更新。
### 原因
原代码在扫描每个音频文件时都调用 `is_valid_audio_file()` 打开文件读取文件头来验证有效性，这个IO操作很慢，导致：
1. 扫描速度极慢（每秒只能处理几十个文件）
2. 进度更新间隔太大（每500个才更新一次）
3. 用户无法看到实时进度
### 解决方案
将扫描分为两阶段：
1. **快速收集阶段**（status: scanning）
- 只检查文件扩展名，不打开文件
- 每1000个文件更新一次进度
- 速度：每秒可处理数千个文件
2. **验证阶段**（status: scanning）
- 检查文件有效性（大小、文件头魔数）
- 每200个文件更新一次进度
- 显示有效文件数量
### 修改的文件
- `python/api_server.py`: 优化文件扫描逻辑，分两阶段处理
- `tauri/src/views/Batch.vue`: 前端支持扫描阶段显示进度
### 关键代码位置
- `api_server.py:1344-1397`: 文件扫描和验证逻辑
- `Batch.vue:36-76`: 扫描阶段的UI显示
- `Batch.vue:215-225`: 进度百分比计算
| `processWebmTranscode()` 异步返回值无效 | 移除 `@Async` 注解 |
| `deleteSfxByIds()` 未加载标签 | 新增 `findByIdInWithTags()` 方法 |
| `removeTagFromSfx()` 缺少关联清理 | 添加 setSfx(null) 和 setTag(null) |
| `batchUpdate()` 循环内多次 save | 新增私有方法，统一 save |
---
## 2026-03-16 SfxService音效和标签增删改查逻辑修复
### 问题描述
检查SfxService的音效和标签增删查改逻辑，发现以下脏数据风险：
| 优先级 | 问题 | 位置 |
|--------|------|------|
| P0 | decrementUsageCount无边界检查，会产生负数 | TagService.java:172-184 |
| P0 | deleteSfxAllTags未清理中间表SfxTag | SfxService.java:726-741 |
| P1 | batchUpdate循环内标签计数重复递增 | SfxService.java:845-875 |
| P1 | deleteSfxTag索引更新顺序不当 | SfxService.java:700-724 |
| P2 | clearNotApproved未加载标签关联 | SfxService.java:950-972 |
### 修复内容
#### 1. TagService.decrementUsageCount 添加负数检查
```java
if (tagStats.getUsageCount() > 0) {
tagStats.setUsageCount(tagStats.getUsageCount() - 1);
tagStatsRepository.save(tagStats);
}
```
#### 2. SfxService.deleteSfxAllTags 添加中间表清理
```java
sfx.getSfxTags().clear();
sfxTagRepository.deleteBySfxId(sfxId); // 新增
```
#### 3. SfxService.batchUpdate 使用Set收集标签统一递增
```java
Set<String> addedTags = new HashSet<>();
// 循环中添加到Set
addedTags.add(tagName);
// 循环后统一递增
for(String tagName : addedTags) {
tagService.incrementUsageCount(tag, SfxCategory.SFX);
}
```
#### 4. SfxService.deleteSfxTag 优化索引更新
```java
if (sfx != null) {
audioEffectService.indexAudioEffect(sfx);
}
invalidateCache();
```
#### 5. SfxRepository 新增 findByStatusNotWithTags
```java
@EntityGraph(attributePaths = {"sfxTags", "sfxTags.tag"})
Page<Sfx> findByStatusNotWithTags(int approvedStatus, Pageable pageable);
```
**经验总结**:
- `@Async` 方法不能直接使用 `HttpServletRequest` 对象
- 需要在调用异步方法前提取所有需要的数据
- DTO 模式是解决此类问题的标准方案
---
## SfxService 音效文件和标签增删查改逻辑修复
### 2026-03-16 修复 SfxService 内部逻辑问题
#### 问题描述
验证 SfxService 内部音效文件和音效标签的增删查改逻辑，发现以下问题：
#### 问题1: `processWebmTranscode()` 异步返回值无效 (严重)
**问题原因**:
`@Async` 异步方法返回 `boolean` 类型，调用者 `moveToNewPath()` 立即得到默认值 `false`，
导致转码还没开始就被判定失败，然后删除已移动的文件。
**解决方案**:
移除 `@Async` 注解，改为同步执行，确保返回值正确传递。
#### 问题2: `deleteSfxByIds()` 未加载标签
**问题原因**:
`findByIdIn()` 没有 `@EntityGraph`，标签集合未加载，导致标签计数递减逻辑无法正确执行。
**解决方案**:
新增 `findByIdInWithTags()` 方法，使用 `@EntityGraph` 加载标签关联。
#### 问题3: `removeTagFromSfx()` 缺少关联清理
**问题原因**:
移除标签时未显式清理 `SfxTag` 的双向关联引用，与 `updateSfxTags()` 方法不一致。
**解决方案**:
添加 `tagToRemove.setSfx(null)` 和 `tagToRemove.setTag(null)` 确保关联清理一致性。
#### 问题4: `batchUpdate()` 循环内多次 save 效率低下
**问题原因**:
每次添加标签都触发 `save()` 和 `invalidateCache()`，效率低下。
**解决方案**:
新增 `addTagToSfxWithoutSave()` 私有方法，循环结束后统一执行 `save()`。
#### 修改文件
- `src/main/java/com/imdaxiong/bigbearcloud/service/SfxService.java`
- `src/main/java/com/imdaxiong/bigbearcloud/repository/SfxRepository.java`
#### 修复汇总
| 问题 | 修复方案 |
|------|----------|
| `processWebmTranscode()` 异步返回值无效 | 移除 `@Async` 注解 |
| `deleteSfxByIds()` 未加载标签 | 新增 `findByIdInWithTags()` 方法 |
| `removeTagFromSfx()` 缺少关联清理 | 添加 setSfx(null) 和 setTag(null) |
| `batchUpdate()` 循环内多次 save | 新增私有方法，统一 save |
核心问题是：文件名中的中文部分是后期不准确的直译，而英文部分是准确的原始描述。需要优先使用英文部分进行翻译和标签生成。
- 英文部分是准确的原始描述，中文部分可能是后期不准确的直译，应优先使用英文部分
- 过滤无意义内容：天途影像、X 2 数量标识、错误直译词
- 单个中文数字（一、二、三等）应保留，不应被过滤
- 保持代码修改已提交到 git
Discoveries
- 问题根源：
_extract_english_part方法从完整路径提取英文而非只提取文件名 - 多层过滤问题：多个地方都有
len(word) >= 2的过滤条件，导致单个中文数字被过滤 - 需要修改的位置：
_extract_semantic_words中的语义提取_filter_meaningless_tags中的标签过滤_generate_natural_language_filename中的文件名生成
Accomplished
- 新增
_extract_english_part()方法提取英文部分（已修复路径问题） - 新增
_optimize_filename_with_llm()方法使用 Qwen 模型优化 - 扩展翻译词库（鸟类、猫、狗、身体部位、数字等约150词）
- 扩展
label_to_tags映射表（约120词） - 修复
NameError: quoted_content 未定义错误 - 添加缺失的翻译词：finger→手指, five→五, six→六 等
- 修改多处过滤逻辑允许单个中文数字通过
正在修复：单个中文数字在最终文件名生成时仍被过滤的问题
Relevant files / directories
python/classifier_v2.py- 主分类器，包含文件名处理逻辑_extract_english_part()- 提取英文部分_extract_semantic_words()- 提取语义词_generate_natural_language_filename()- 生成新文件名_translate_filename_to_chinese()- 翻译英文到中文_optimize_filename_with_llm()- LLM优化文件名
python/utils/tag_generator.py- 标签生成工具extract_filename_keywords()- 提取关键词_filter_meaningless_tags()- 过滤无意义标签MEANINGLESS_TAGS- 无意义标签列表translation_map- 翻译词库
python/utils/local_llm_tags.py- 本地LLM标签生成器
File: Five finger whistles..07034113.wav
Semantic: ['五', '手指', '口哨'] ✅ 正确
Keywords: ['五', '手指', '口哨'] ✅ 正确
CN Tags: ['五', '手指', '口哨', ...] ✅ 正确
New Name: 手指_口哨_2df943.wav ❌ 缺少 '五'5X3W-33Q7-A5RA-6E93 RRLA-S397-B7QA-4R2E
DVYU-S5WC-8GEZ-8NTN M786-3DSD-HJ5P-PGFD
Y8L3-XKU2-U5F4-K6BN ECUH-XPSJ-MFU5-T5A2
84E4-4565-Q46P-7U9H 9S6S-8QJH-P2DL-RRU7
JZL3-YR8D-FL3L-TRR6 L7X7-B349-V5ZS-R93U
目前有大批的音效超过万首以上待审核
过去的音效分类工具虽然用了大模型
但是对于音效这种短音频文件
很难识别的特别准确
所有我整合了三个模型来做智能音效分类
希望能够尽快的完成音效库的搭建
毕竟工具体验再好
资源不完整也是白搭