wyd011011daniel

@wyd011011daniel #38 因为我觉得阅读作为安卓的比较领先的阅读软件，iOS 上并没有能够与它太好进行竞争的软件。如果能做这样的适配，我觉得能在一定程度上吸引从安卓转 iOS 的阅读用户。同时，我觉得这样子可以借助社区社群的力量完成大部分 TTS 服务的适配，也是一件好事

@wyd011011daniel #37 嗯，这是爱阅记的听书配置文件的 JSON 文件直接复制。甚至我觉得可以直接按照类似爱阅记或者阅读的模板直接进行导入因为无论是字节或者百度之类的 TTS ，这样的模板已经有较大的应用，我看到很多用户就是按照这样的模板直接填入自己的 API 进行听书，很多用户也会分享和使用，如果能够参考这样的配置文件就可以把这方面的用户进行一个吸引{
"loginUrl": "",
"maxWordCount": "",
"ratePercent": 0.5,
"ttsConfigGroup": "Azure",
"_ClassName": "JxdAdvCustomTTS",
"_TTSConfigID": "对应的 id",
"httpConfigs":
{
"useCookies": 1,
"headers":
{ }
},
"ttsHandles":
[
{
"paramsEx": "",
"nextPageForGetMedthod": 1,
"processType": 1,
"maxPageCount": 1,
"method": 0,
"requestByWebView": 0,
"nextPageParams":
{ },
"parser":
{
"playData": "ResponseData"
},
"url": "https://eastasia.tts.speech.microsoft.com/cognitiveservices/v1",
"params":
{
"text": "<speak version=\"1.0\" xmlns=\"http://www.w3.org/2001/10/synthesis\" xmlns:mstts=\"https://www.w3.org/2001/mstts\" xml:lang=\"zh-CN\"><voice name=\"zh-CN-XiaoxiaoNeural\"><prosody rate=\"-34.00%\"><mstts:express-as style=\"lyrical\" styledegree=\"1.6\">%@</mstts:express-as></prosody></voice></speak>"
},
"httpConfigs":
{
"useCookies": 1,
"customFormatParams": "params[text]",
"headers":
{
"User-Agent": "AiyueTTS",
"Content-Type": "application/ssml+xml",
"X-Microsoft-OutputFormat": "audio-24khz-48kbitrate-mono-mp3",
"ocp-apim-subscription-key": "对应的 key"
}
}
}
],
"_TTSName": "Azure 晓晓 gentle"
}

@jobives2023 #34

我对 API 兼容性还是挺期待的。如果开发者适配不同模型是有一些难度的话，建议可以引入类似“爱阅记”的自定义模式，允许用户自主配置 HTTP 请求。

对于具备一定技术基础（如了解 API 概念、熟悉云服务账户注册）的用户而言，在 AI 的辅助指导下，完成这类配置并非难事。如果平台能够提供可视化的自定义配置界面，或者支持导入他人分享的预设配置文件（简单的 json 文本），普通用户便只需填入自己的密钥（ API Key ）即可直接使用，这将大幅降低操作门槛。也就是说，每一个 AI 服务或者说语音 TTS 服务只需要某一个人完成适配，然后上传到例如 GitHub 的仓库里，就可以让所有用户一起使用，只需要填入自己的 API key 。此外，鉴于目前诸如小米等厂商已开放了自身的 TTS （语音合成）云服务，我觉得应该是有一定前景的。实际上阅读，爱阅记等软件就是这么做的。

然后你说的情感朗读，我知道真正的情感朗读是要带情感标签的，但是我自己是把语音情感当做一个全局化的设置作为特定音色进行听书。嗯，或者软件里的 TTS 使用的是 Azure 的 TTS 的话，也可以把那些情感类型和情感强度的选项加上。不过，Azure 的 TTS API 还是挺贵的，所以我期望是能够让用户用自己的。这样可以减轻开发者的负担

嗯，考虑到你说的是 58 块钱的买断软件，因此我设想它是一个不太需要很大的云服务成本的软件，假设它是一个离线的软件，假设它是 iOS 上的，那么我希望 58 块钱购买了一个离线的，不需要云服务器的软件，然后开发者在未来的生命周期里，续费他的开发者账户，并且每年进行基本的软件 API 的维护，我认为是合理需求。

嗯，有以下几点原因
首先是因为软件有大量开源软件或者免费工具通过广告赚钱的那种免费软件的竞争，然后还有 AI 能力的增强开发一个同类的相似软件的门槛成本并不是很高

其次是从经济学原理上讲，实体商品的生产成本边际成本是永远存在的，但是软件开发完成之后，无论是卖给多少个人，开发者的分发成本基本上没有变。比如说从苹果开发者的角度来讲，只要你续费每年 99 美金的开发者账户，你就不需要再出任何钱。当然我说的是离线软件的情况下。

最后是如果开发者需要进行一个长久的大量的维护或者是云端储存算力的开销，那么我认为，开发者应当转向订阅制。

或者换个角度说，用户花了 58 块钱购买了一个不需要云服务器的应用，那么开发者赚回每年的 99 美金。这件事情基本上不很难，特别是你卖出几万份的情况下，每年还可能再新增一些长尾用户，然后开发者还会开发其他软件，那样子他的 99 美金的年费就会平衡地分散到几个软件上，那么他相应的每个应用的成本也会特别低。然后只是对软件进行一个基础的应用维护，适配一下苹果例如 iOS 26 的玻璃动效这类效果，它的需求应当不是很大，所以我觉得是长久维护是合理的。就是你不提供新功能，然后你贩卖的是你的这份代码，然后你有一点点售后的感觉，把那些 API 进行一个稍微的适配。

同时，开发者的长尾维护这个行为也会持续增加，吸引更多新用户，而如果新用户看到你不再维护软件了，它自然就不选择购买，这是一个双向的选择。

询问一下是指没有打开网页全屏的情况下，可以去掉折叠评论区吗？因为在网页全屏的情况下，好像是有这个按钮的。因为我一般会默认打开网页全屏

我觉得可能的路径是这些第三方的相机软件，尽快地推出一些原生的效率更高的 APP ，类似于大疆 Mimo 。然后用户只需要用极简单的方式打开 APP 就可以快速导入照片到手机进行修图或者整理。反正我觉得做硬件这件事情 iPhone 是不需要做的，相反是那些硬件相机是需要去做软件来适配更现代化的工作流程。

我理解你认为对那些更大底片的相机的一个需求，但是我认为苹果做一个更大底的相机这件事情既不符合苹果的商业逻辑，就是苹果并不会赚到特别多的钱，同时 iPhone 的能力上限已经很高了，就是可能换一个更大的底并不是那么重要。

iPhone 能够拍 OpenGate 的视频，并且能够进入专业影视流程 F1 电影这样的影视工作流，那么它甚至在某种程度上是比微单相机还要厉害了。

富士或者其他那些风格化的微单相机，其实他们卖的某种程度上是一种风格或者算法，而苹果它不太在意，或者说风格或算法可以由第三方来完成。