关于使用程序处理(由AI,FFT技术从音频转化的)MIDI的想法与思考

首先要注意,这些技术本身的普及是难以阻挡的趋势且本站也看到一些未经修整的音频直接转的MIDI(主要集中在纯钢的作品 所以接下来重点先讲这个)所以这是一个不得不面对的问题。(关于社区,和直接传这种粗糙的MIDI行为的思考放在最后。)

我在想,是否能更进一步让机器处理大头,而人处理细节?
先来明确任务:
输入一个粗糙的,程序转的MIDI(钢琴单轨) (只考虑原本就是纯钢的或者近似的那些音频转的MIDI)
输出一个可以被曲谱软件读取,并且以“人能读”的谱面显示,同时尽可能保留原汁原味的MIDI

尽管大体看上去像是那么一回事,不过这其实还是不明确有很多的主观成分在里面:
比如什么叫程序转的?到底是那些程序?那些技术?什么是原汁原味?等等
我目前的思路是先从PianoTrans的输出入手,且聚焦在输出后的midi而非直接分析PianoTrans内部的过程。大概分为三个任务

  1. 事件的时长重写(因为PianoTrans对所有的踏板都会进行一种非常奇怪的操作导致踏板触发的那部分事件的结束时间普遍延后到该踏板结束)

  2. 事件的时间对齐(让MIDI能被曲谱软件以正确的方式读取,这并不是说曲谱软件不能读MIDI,而是让那些事件恰好能塞进曲谱里面 而不是做出很多匪夷所思的内容)

  3. 事件的修补(比如不应该有的音,和缺失的音。但这部分困难的多,可能凭借乐理知识写出的程序流程并不总能完成任务 ,但希望能尽可能减轻人的负担 ,但又不给人增添负担 比如做出一些很蠢的操作)

目前我做了1的一部分,让这种midi辅助人来完成扒谱的程度是达到了。
另外附上一些机器转的midi的材料
liszt-叹息.mid (18.4 KB)
Daniil Trifonov - Grandes Études de Paganini, S_ 141 - VI_ No_ 6 in A Minor .mid (30.1 KB)
Carl Doy - Autumn Leaves (Album Version) .mid (6.3 KB)
两首阿拉伯风格曲,L.66第一首-生动的行板.mid (18.2 KB)
这里是TutorialsByHugo的视频转的

残酷天使的行动纲领.mid (1.3 KB)
站内相同主题手工版midi
(这里的只有前面一段)
Factory NoiseAG - ヴォヤージュ1970.mid (10.4 KB)
这个下面有对应的谱

最后是关于社区,以及直接传这种音频转的(机扒?)MIDI,我的思考是
1.目前技术上看,这种音频转MIDI未达到人做的水平。灌水这种内容会降低平均质量

2.在1仍然成立的情况下,我们应该去主动利用社区的相关机制来抵制这种低质量作品,且自己不去发布那种未经修整的低质量作品,(但使用这类工具辅助扒谱是可行的)

3.不可否认的是,技术本身不断进步的趋势(可能也会不断普及),所以需要以变化的观点去看这件事。作为工具,在确认其确实有用的情况下去使用,而不依赖工具。(这里仅仅就钢琴扒谱来说,依赖程序工具,而非锻炼自己的听力对长期发展来说是有害的)

4.社区的和谐与稳定是建立在大家在一些观点上相互尊重,在核心观点上一致认同的前提上。

1 Like

非常感谢 @SSSSatori 发送长文讨论自己的感想。


在我看来这是正确的(至少是良性的一环)

说回扒谱,在现代阶段主要有两种办法:

耳听用眼看频谱

不过这些都是停在人工的阶段,即使技术再高超的人也难免会犯一些错。

我属于耳听派,虽然不太懂频谱分析(也的确离我专业范围太远了)。只能说以上感同身受


用"机器(ai,脚本,无论什么自动程序)"去替代这些工作

首先脚本或自动程序那肯定没有技术成熟的实例(第一个被排除)

开始认为AI应该能做频谱分析吧(不仅如此"机械性重复运动"总比python强吧),就照着这种思想。
好好幻想了一波 ai自动分析信息,输出的画面…

(不过现实给我泼了桶冷水)


不是,现在用AI在发展什么东西。


排除上面的技术弯路,把傅里叶转换这个工作交到 AI手上的项目,至少公开的我没见过。

只要AI音乐这两个词加在一起,就必定会出现上方搜索栏的东西(就问脑袋痛不痛)

但我想想,傅里叶转换卷积神经网不能说是门当户对,也只是说毫无关系。

(这一章就当我怒喷大环境,请忽略此文)


回到最初的话题,既然都有人用眼睛去看频谱了,那么让AI分析频谱自己出来也没问题了。

算上问题的话

  1. 人在看频谱的时候基本会自己把问题排除完。
  2. 但ai不会,所以就有了手动修改这步。

但好好想想的话,其实在看频谱这一步每个人其实都一直在做修改行为。包括耳听的也是

AI生成以后要修改,看频谱耳听也要频繁修改。

得出结论:

Ai(自动分析)好用,爱用

尽管用吧,我作为耳听党对一个谱面扒出来保守的时间是三个多小时(调预设是一部分,频繁修改又是另一部分,时间就没了)

所以,如果不忘记修改这一步,那么我都全力支持。


这是我的观点

26 08-09 20:53 utc+8

1 Like

我想知道您指的是哪一种?是任意的音频然后去做分轨的那种扒谱吗(或者说扒带?我也不清楚具体术语)。

就目前来先除去那些AI生成音乐来说,这是有的但不在我想讨论的范围(似乎也有那种端到端的midi直接生成技术 但我没体验过仅仅是听说有这些研究)。

而就一般的扒带来说我搜了一下有如 music-to-midi这样的项目 也有商业的 软件,不过我没有体验。这里暂且不说(而且我也不了解很多乐器,就算体验也难以给出一个评价)
不过我讲一个更细致的吧,字节跳动有一个GiantPiano的数据集 就是大量的钢琴midi文件。在这个数据集的建立中使用了人工智能技术(就是先爬虫油管钢琴视频,筛选合适的,最后用卷积神经网络把这些音频转成midi 这里的detect也就是筛选本身也用了CNN,而后面的transcribe是用的CRNN 摘要这里没细说),

(原谅我没给原文链接,有点懒了)然后关于PianoTrans来说 似乎也有相同的技术(相关论文其实十多年前就有),总的来说深度学习对处理这类任务已经展示出一些能力了。(似乎国内腾讯也在做相关研究)

当然了,我仅仅只是浅尝辄止的学了一些机器学习的内容,对这种工业级的项目是无能为力的。
但我有些想法,而且算不上是我独一份的。那就是用midi集去生成训练数据。
但我思考的是我们怎么样的设置midi集,可以让生成的数据足够让模型去学会应对大量常见的任务,而不陷入过拟合。如果有一些数学,物理,声学,还有和人的感官感觉相关的科学的支持,那我想这个任务的模型,特征工程,特征交互等等设计会事半功倍,毕竟那是我们知道的千真万确的真情实感
哎,扯远了。总的来说我认为未来这会越来越发达的,(但对大厂来说,训练一个音频转midi的模型可能在实用性和性价比上比不上雇佣那些熟练的音乐人,所以没有那种出于生产的动力去驱动这个领域发展,更多的是好奇和一些前瞻性的战略部署。)
最后突然有感而发:
无论端到端再怎么完美的解决我们遇到的问题,但总有那些需要我们御驾亲征的地方,那些感受,那些源自深处的,非功利性的动力,或者说-音乐的意义

1 Like

这也是大多数人的常态,这么理解对的。


剩下我能说的不多,就来分析上面情况

这个是因为没有先取得曲速,直接识别的后果。
并非没对上,遇到变速/变拍立马就老实了。

取决于音频文件本身


这条就和上面说的一样取决于音频,AI分析频谱不会放过任何一个细节

就是因为这样乱七八糟的东西就出来了,所以说有个叫灵敏度的东西(是这么说吧)

再加上算法对于可能是那个音的预测,感觉多少就跟AI幻觉一样,是甩不掉的(至少不能避免)

不过还是说有个叫"灵敏度"的东西,不清楚在这个头适不适用


毕竟本主题还是聚焦于优化mp3-to-midi的输出结果,我就不去说用ai替代Python了。(抱歉)

26 05-10 01:22

这种情况并不鲜见,像早期音序器(总之是音乐软件)还没统一天下的时候。

各种软件工程文件互转满天飞,对不准时值倒也算很正常的事了。

所以有把时值单拎出来的软件,对不准过于离谱请自调。
IMG_20260510_012622
(这些软件想拖动整个乐谱是不现实的,一旦音符转过来的话,要么改时值,不然也可以不改反正耽误事。最多也就是循环点会出毛病,这真的头痛)

说人话:上面直接拽整轨会缩进,因为是mono通道的缘故不准让两个复音在同一条通道上


这种事情都是在历史上演过的,是不是再来一遍了嘛

01:36

1 Like

这里放两个对相同内容的扒谱的链接,但是一个是AI方法,另一个是手工的(本站没找到直接对应的手工)
手工,B站
AI,本站
不过是纯钢的内容。我感觉比起FFT还是更强的,(不过还是看情况如果本身是很急促的那种音乐那AI的效果不会很好)。就AI的技术层面来说并不是什么细节都不会放过的(因为那样会过拟合,缺乏泛化能力,比如如果音频中有一个什么意外的声音(噪音)那AI会把这东西同样学到,显然这不是我们想要的结果)
起码在纯钢这个范畴内我感觉很多时候人工智能做的够好了。(但前面说的,未经整理,量化的midi文件上传到社区没什么意义,毕竟软件是公开的,传一个其他人没法直接用的资源,难道只能听个响吗?)
有点跑题了,= , =
但问题是,不是机器没有取速度,而是由于细微的随机性和机器学习泛化能力的要求,其输出的midi文件事件本身就不是对齐的,即使在AI效果够好的情况下,仍然是有那种出入(所有的时间相关的量大概会稍微的早一点点或者晚一点点,但听感上并没有差别,不过对直接得到谱子的那种任务来说是有问题的,尽管有一些适应机制允许小范围的偏差,但是在比如琶音这些对精度要求更高的记录是困难的)

举个例子,这也是对同一个内容的制做(这个是我搓的,即使不标注应该也能分辨那个是机器那个是人工),最关键的是听觉上其实是差不多的 (暂且忽视一下那个速度记号,机器谱的速度是正确的(和原曲进行对比的化),人工的是测试一下其他速度)
(把midi直接丢MuseScore会损失一些音,这可能是因为谱面最多只能让单个钢琴有四个声部,和一些在间隙的MuseScore识别不了的音导致的)而机器的midi在听觉上差不多了(换个方向来看,这对于纯钢作品来说可以当成超级压缩?毕竟力度,踏板什么的细节也有,而体积大小减少几十万倍)

而事件的修补,我不是说去改AI模型,而是改AI的输出结果,把那些显然不合适,或者大部分情况下都不应该如此的内容给修改了,作为对人力工作的减轻(同时,不要过度的处理,比如程序犯蠢导致反而增加了人的工作量,我对完全优化,完全当甩手掌柜这种程度不抱希望)。
最终在辅助的情况下说不定熟练的人能在几分钟乃至更快的完成五分钟左右时长的音频的扒谱。(不过为什么要这么快?起码对我来说扒谱快到一定程度后可能其他东西开始限制个人了,比如就算扒出来也不能缩减练习的时间,这条道优化到头了并不能改变一些根本性的东西)
另外,我最终聚焦的目的大概是做出什么程序去自动执行那些重复的可以被规则直接描述的工作,但AI转出midi然后再人工修整的这种模式,和前面的看频谱的模式是不同的。
从技术上看,我也不清楚有没有那种AI去读取(看)频谱就像人一样做的,但似乎目前人工智能转midi在路线上并不这样子的。(等闲了看看相关论文,可能打脸)

2 Likes

其实你可以直接在这里上传MIDI文件。

先说结论,

每一家的自动转换脚本(例如lua)算法上都相差甚远

如果用多个不同软件这种感受会被无限放大(但这并非是讨论的主题了)


midi转译后变成musicxml,该文件的通用性几乎属于灾难级(那就是没统一标准,各家都有自己的规则(通用兼容的地方几乎能忽略不计),导致上面那个情况,就要像某位老师讲过的:"动手做XML不要拖MID(用来偷懒已经绷不住了)"


但也是八阵偏离主题了,容我一句实话自动脚本是死的。 AI有概率能是活的(希望如此,拓展规范的互相不兼容。不多举例子应该也明白的.mid就是这样的文件)


这楼主题跑偏了就算了,在下一楼回到钢琴谱上。

本楼主题聚焦于mid-to-m_xml

2605101219

感觉那类作品没什么应用的价值(吧?),虽然说对钢琴卷帘的那种操作来说是足够的。(不过正如前面说的一样,软件是公开的,且运行的需求也是民用设备可以满足的,那这样灌水岂不是对不起其他认真做的人?)

2 Likes

他说的是点击讨论区这里的上传按钮可以,上传几个错误示例到这边服务器(当然不是直接上传到主站里面当作品)

这些文件可以直接上传到附件

2605101242

2 Likes