都是一些零碎的想法和个人经验。考虑到相关的中文资料实在不多，整理出来，供愿意折腾这个的人参考。
1：版权
做 podcast 之类的原创内容就不说了，就说说上传点儿 mp3 听歌儿这个事儿。
无论是否能证明“自用”，反正你公开页面又没有密码，D版这个事儿是一投诉一个准儿的。再说，个人用的话可以考虑其他服务，比如Koel什么的。
那么，就牵扯到服务器选址的问题了。其实，我之前有个站，跑了3个多月，2个电台，也没人给我发邮件什么的。估计是流量太小，没人搭理我……
看看V家那几个可选的国家：美国、日本、韩国，这都是版权管得严的地方，不用考虑；德国的话，就上网体验而言，有些网盘都屏蔽德国IP的……估计也很严。
刨去几个丢包严重的，我一直以为荷兰是最不爱管这事儿的。结果今天看到了一个论文，有点儿出乎预料。
引用一段儿文章内容：
欧盟整体而言，司法实践中适用三步检验法的欧盟国家可以分为严格与宽松两种类型。前者如法国、荷兰、比利时等国，遵循WTO专家组在Fairness inMusic Licensing（DISPUTE DS160）一案中的判断标准；后者如德国、瑞士、西班牙等国，对于三步检验法的适用标准则较为宽松。
于是我又去看了一下服务商。发现一些跟我之前“以为”的类似的想法。不过，搜一下就能发现，所谓“抗投诉”的服务商，好像各个国家都有。
常识层面而言，XX主义郭嘉就是不怎么管这个事儿，全世界D版最严重的应该就是老毛子。当然，这里指的是行为。如果你问我人数儿的话……你觉得呢？
实话说，这个事儿我也没有答案。我当时只能在荷兰和端典（@CC）两个中二选一。如果谁有更好的建议，请看完全文后指点我一下。
2：存储与音质
就之前的测试来看，带宽并不是什么要担心的事儿。azuracast甚至支持 FLAC 。当然说，320K 的 mp3 也很可以了。考虑到很多人的实际情况，192和320并不是一耳朵的区别。而 podcast 的话，系统默认的128或许都能提供足够好的体验。
但是问题就在于，我这个人吧，比较事儿逼。在某些大动态音乐的场合，你再弄个降噪耳机（甚至听稍微好点儿的便携蓝牙音箱），192确实差点儿意思。所以我之前一直都是开 192（默认）和 320（可选）的两个挂载点。而上传文件的时候，我也不太可能为这个，再去把每一个手里的320文件转成192的。
按照逼乎某个帖子的说法，1分钟的320K文件，60*320=19200kb = 2400 KB = 2.34375MB 虽然附加信息会增加文件体积，但是有些文件的编码是浮动码率的，会稍微减小文件体积。（说来惭愧，我本科毕业设计就做的这个相关的东西，全特么忘一干净，就记得答辩时候的尴尬了……）
那我们就按照这个数值去进行计算。得出的是3.375G / 天。而一周如果想不重样儿地进行播放，最少需要23.625G，才能维持一个电台，一年的话需要1.23T。实际上，传文件的时候，肯定不会死死卡着时间传吧？这个数值还会被向上修正。拿V家的5块钱主机举例，装完服务，还剩16G的硬盘，连一周都不够放的……
所以，我也稍微看了一下1G内存的大容量主机。如果不考虑 openvz 主机的话，实话说，5刀的选择并不多。这个大家自己去搜吧。在这个问题上，我个人并不倾向于年付主机。如果要牺牲灵活性，我宁可不折腾这事儿了。
另外一个思路是，买纯存储的服务器，挂在上面。这个也会牺牲一定的灵活性。拿V家自己的举例，单价为：1刀 / 10G / 月，最大可以扩充到 1000刀 /10 比他们家那个6刀的套餐好像更适合做这个。我自己用的都是 kvm 的主机，不清楚那些便宜的 openvz 主机如果仅仅是做存储的话，性能如何。就留给会折腾的人去折腾吧。
3：流量
如果不牵扯挂存储的话， 320K单电台的月（时长）流量约为105G。应该不会有人10个人7*24开着网页耗你流量吧……所以，即使是只有1T流量出站的套餐，也足够个人/小范围使用了。
但是，如果牵扯到外挂存储，这个应该也有一部分流量。不清楚那种“自家服务器”的存储是不是就不算流量了（我估计是要算的，除非是那种网页控制时候就可以直接挂的）。这方面，我短期不会去碰。有懂的说说吧。
另外，有些服务商有无限流量的套餐。虽然这种拿来架梯很可能会被 QOS 甚至挂掉，但是，在这个应用场合，也许是可行的。
当然，我知道有人把自家电脑直接做成存储服务器，挂在公网上面的。在这个场合，肯定也是适用的。之所以不考虑这种方案，主要还是考虑了版权方面的风险。你看那谁，那谁，还有那谁……
4：服务器配置
之前在架设那篇里面就讲过了，ubuntu 20.04 + 1g ram 直装是没问题的。有必要的话，我会在未来找人帮忙进行压力测试，看看能同时跑多少个电台。不过考虑到前面说到的问题，在这个场合，存储才是最大的瓶颈。
至于docker的版本，也许官方建议的 2g ram 起步才是最好的选择。SSL的事儿也就没那么多废话了。当然，如果你想拿这个服务器干82件事儿，努力榨干性能。我觉得吧……还是考虑 cloudron 自带的那些服务吧。一个人自用的话，蛮好。干嘛非要跟这五块钱的东西较劲……
5：曲库管理
如果懒得折腾服务器备份，那可以跟我一样，在本地建个目录，把要上传的文件都分类放好。如果服务器哪天崩了，也好重新上传。如果没有太多个性化需求，这套系统安装还是很快的（熟练工的话用不了一小时），网页层面的设置也就是15-60分钟的事儿（取决于你开了多少个电台）。
说到这个，其实就牵扯到两个话题。一是ID3管理，二是文件/文件名管理。这其实都属于本地数据管理的范畴。其实，大多数正规网站 aka 正规D版网站，都有相关的发布格式。下回来需要手动整理的并不多。我平常是用foobar的，一般而言，拖进去的时候，就能看见发布者有没有按规矩办事儿了。当然，如果需要从镜像式文件转成 mp3 再发布，这就不是本文要讨论的范畴了。说白了，还是一个“平常养成好刁惯”的话题。
和foobar一样，azuracast 对于 Big5 的支持似乎是有点儿问题的。甚至，有时候会发现 GB 和一些非英语字体也会出现乱码的情况（旧版本的情况，新版本不知道改进了没有）。我个人是并不太介意这件事的，因为我听的中文歌儿并不多。介意的话，自己去学学 ID3 管理/管理软件吧。
如果这些部分都能做好的话，那在上传文件的时候，就可以整个儿目录直接照搬了。然后全选一下，拖到播放列表里面，稍微修修次序（如果需要的话）。非常省时省力。
6：节目设置
终于到了谈“内容”的部分了。实话说，我到现在，还没想好这个事儿怎么办……
之前的某个电台，是靠“分时段播放固定节目”的思路来安排的。比如，每天在 7-8 、10-11 、14-15……分别播放同一个节目。按照这样的思路，确实可以节省一些存储空间。而另外一个“每小时变更节目”的，大概用了7G左右的空间，也就是最低门槛的两倍左右。在我看来，如果节目内容是随机的播放列表，那么2-3倍时长的备选曲目是必须的——主要是为了保持新鲜感，尽量能让听众每次点进来都听到不同的歌儿。在这个的基础上，再计划每周 / 每月更新节目内容。
说到这里，真心觉得，这挺辛苦的……如果要我这么做，那得给我全职工资，不然我真弄不动……
在节目设置上，我其实有考虑几种模式。从不同的tag（如 风格、类型、艺人、功能性、经典、新曲推荐、podcast、曲艺……等）切入，会出现不同的排列组合。不过，从我的角度看，网络电台和传统电台最大的区别还是：网络电台的类型化高得多，不像传统电台那么适合做综合性电台（也很难投入那么大的人力成本）。就像我前段时间特地去下载某个电台的 APP，进去也是只为了听某个节目的回放。
这个没法铺开讲了。牵扯到“理念”层面的东西了。也就是说，你做这个频道是要实现什么——剩下的都是手段。
就我目前的情况而言，我只能就着现有的硬件条件，考虑一下自己能做什么，然后再做一下取舍。
回到最初的想法，其实我的“初心”主要是两个。一个是听一些经典作品，尤其是那些百听不厌的爵士乐（在电台随机听古典的风险太大了）；一个是整理和分享一些新歌，让更多人（包括我自己）了解那些新的+有趣的艺人/作品，我没有盈利的打算，更没有商业层面的考量——这导致我可做的事情会很多，反而把事情弄复杂了。
更具体的计划，等频道上线的时候，视情况再开一篇细说吧。
7：网站维护与安全
安全这方面我能讲的不多，基本上也就是常规的那些东西。比如 linux 的安全更新，密码管理之类的。如果你搭建过WP，这相关的东西肯定知道不少了——没试过的话，强烈建议试试，可以学到很多最基础的知识，而且有足够友好的中文文档可以参考。
而网站维护方面，除了前面提到的内容维护，在这里还想强调一点。
从我个人的经验来看，很多用户并不知道“广播”是个什么东西。会问“为什么不能下一首”这种问题。所以，如果不能给新手用户一个简单的说明文档，有些功能（比如点歌）要慎重开放。免得造成废话。幸亏我是为了好玩儿才研究这个，如果是个想拿这个干点儿什么的，估计早就被问疯了。
——————————文末的分割线————————-
p.s podcast功能刚刚启动，目前（的版本）还是个测试。我大概看了一下，做得挺好的，足够用了。如果我会在未来做语音节目（仅仅是个假设），肯定会考虑在这上面进行发布的。
