forum

[Proposal - Audio] Embedded images must be removed

posted
Total Posts
24
Topic Starter
Ryu Sei
Hi. I made another proposal in regards of some audio files may contain embedded images (usually in form of jacket/album art). These embedded images do not serve purpose for osu!, just like audio tracks has no purpose in beatmap's videos. As such, this is a simple rule proposal I made, by paraphrasing similar rule on video:

An audio's embedded image must be removed from the audio file. The embedded image in an audio is not used in osu!, and removing it reduces the file size of the beatmap.

I think we need to add this rule since there are no rules or guidelines regulating these, which means there is a potential of wasted space for something we don't even use. In extreme cases, it can bloat the audio file unnecessarily big especially for ogg files since their overall bitrate will be misinformed. Here is the comparison:

As you can see, removing embedded image shrinks down the size from 5.87 MB to 5.75 MB, and corrected the overall bitrate from 200 kbps to 196 kbps.

With this proposal, it results in smaller audio files for a beatmap, and potentially better audio quality for ranked beatmaps without needing to unnecessarily use lower quality factor for ogg due to the embedded image present.

There are some ways to remove these:
  1. Use ffprobe to identify the stream index of audio and image, then ffmpeg to convert the audio so it does not map the image. For example, if the audio index is 1 and the image index is 0, and converting to ogg with Q6, use this:
    ffmpeg -i "input.mp3" -c:a libvorbis -q:a 6 -map 0:a:1 "output.ogg"
    The argument -map 0:a:1 will map the index 1 of source to index 0 of destination. That way, the index 0 of source which contains image won't be mapped, so the output audio won't have embedded images.
  2. Use tag editors. For example, using AIMP, you can right-click an audio file and choose AIMP > Edit tags. This will bring up a window where you can choose what to do with the images.
    Look for the album art on bottom right, then right-click it and choose Delete. Then, save file. It will overwrite the existing file, so no embedded images present on the audio file.
aceticke
This is pretty redundant for such a minor difference in audio quality and file size, and adds even more steps to the already difficult audio checking process for a lot of BNs.
Hivie
i disagree with enforcing this because it's an overhead that's not worth the negligible amount of benefits (saving ~0.1 mb). it's additionally gonna be an additional annoying check for BNs where they already have enough annoying technical checks to deal with, not to mention how it's unreasonable to expect mappers to keep up with all kinds of third party tools to use.

all this overhead is simply not worth it for such a minor difference.
Topic Starter
Ryu Sei
Mappers and BNs can simply tell if the audio file has embedded image or not simply from their default file browser. There are no third-party tools required to check that. You might need these tools I mentioned to actually remove these, which I believe for ffmpeg it's even suggested as a tool (in a collection) to use to check the indexes and convert audio correctly: wiki/en/Guides/Compressing_files#using-ffmpeg.1

Additionally, if you use Audacity (which most people will use if they don't understand ffmpeg), it already removes the embedded image during conversion process, so we can add that to the guide as an extra note.

This proposal will help trimming the audio file while keeping the quality as high as possible according to RC. Lower audio file size means you can put extra files to the beatmap for more objects such as hitsounds and storyboard elements.

I believe there are other examples of audio file being unnecessarily bloated due to embedded images, but I showed you the bad example with negligible size. The bitrate difference should be observed too.
Muse Dash
- Lower audio file size means you can put extra files to the beatmap for more objects such as hitsounds and storyboard elements.

It's just an option which mapper could do when the file reaching the upload limited size...
No need to be enforced I feel.
Topic Starter
Ryu Sei
Maybe if it's a guideline, this is a better option?
Noch Einen
80% more effort/extra unnecessary step (just like multiple tag on each diff)
20% ok if the audio comes from flac / 320kbps

I cant see how this should be a thing where we (mania only) are already having much leniency on checking.

I might get it if for reducing/upgrading audio quality like defreeyay (which avg ppl including me cant hear the difference), but....removing img for the sake of web/server's storage. Will that even make the gameplay better?
Hivie

Muse Dash wrote:

- Lower audio file size means you can put extra files to the beatmap for more objects such as hitsounds and storyboard elements.

It's just an option which mapper could do when the file reaching the upload limited size...
No need to be enforced I feel.
agree, there's no need to enforce this, the upload limit for maps going for rank is very generous so like 99% of maps going for ranked won't ever need to do this.

Ryu Sei wrote:

Maybe if it's a guideline, this is a better option?
for something to be a guideline, it needs to be enforcable with reasonable exceptions, and so far everyone is disagreeing with making this enforcable.
Drum-Hitnormal
definitely don't make this mandatory, the only benefit is server cost, which is not mapper or player concern.

its too technical to expect mapper to know how to do this, and extra work for BN, you will get more benefit from restricting BG to JPG format than this, which is much easier to do as well. and you might as well ban WAV for HS and enforce OGG.

if you make this a guideline, people will use it to QA, which is not worth a DQ.

in fact all these things could be implemented on server side when map is uploaded/updated, perform the conversion on the files and rename any reference for format change, if peppy really want save on server cost, its not a thing for us to worry about.

stop using RC as temporary fix for infrastructure/system flaw, RC is really bloated already
Monoseul
This is an incredibly minor thing to check for and only gives more unnecessary work for such minimal results that almost no map going for ranked even needs to use or look out for. The upload size limit as Hivie mentioned is already so generous - something like this won't affect anything. It's really unnecessary to create a rule, let alone a guideline for this.

It's one of those things that only barely benefits anyone at most and isn't something that needs to be enforced.
RandomeLoL
Going to feed the echo chamber, but I do not believe the benefits of trimming down are greater than the overhead required to start enforcing these checks.

You'd have to actively try to bloat it by abusing the file's Metadata. Those cases are, quite frankly, improbable. Not impossible, but improbable.

Also I'm unsure why your suggested ffmpeg prompt would encode an .mp3 file to .ogg just to treat metadata as VorbisComments. That aside, I do not think this is something worth enforcing or reserving the headspace for.
BadDragon
I've had case on own chart where embedded image was >1MB before , so don't completely ignore checking this.
Apart from that unsure if needs to be rigorously enforced

Addendum: for ffmpeg just putting "-vn" also removes the image as a simpler method
Topic Starter
Ryu Sei

RandomeLoL wrote:

You'd have to actively try to bloat it by abusing the file's Metadata. Those cases are, quite frankly, improbable. Not impossible, but improbable.
It isn't an abuse if the artist themselves providing the audio file with the album art with unnecessary bloat. This is a rare case though, but even Featured Artist templates are prone to that issue, so the players can't be blamed for the bloat. I've seen some on the maps I modded and there are the discrepancies between these three aspects of an audio file with embedded images:
  1. Audio bitrate
  2. Spectograph
  3. Expected file size
For example, a 1 minute mp3 file with correct spectograph at 128kbps but has abnormal file size is an indication of bloat.

Either way this can't be completely ignored, but can't be really enforced.


RandomeLoL wrote:

Also I'm unsure why your suggested ffmpeg prompt would encode an .mp3 file to .ogg just to treat metadata as VorbisComments. That aside, I do not think this is something worth enforcing or reserving the headspace for.
You can use the same arg of -map 0:a:(source_audio_track) when converting to any format. We are talking about embedded images, not metadata.
clayton
I don't think this is in scope of RC as already explained by others -- this kind of thing is better suited for articles like wiki/Guides/Compressing_files
Topic Starter
Ryu Sei
Maybe we can look at this rule for why embedded images must be removed.
There must not be any unused files or 0-byte files in the beatmap's folder. 0-byte files prevent other files in a beatmap's folder from properly uploading. Automatically generated thumbs.db files are the only exceptions.

An embedded file can be treated as an "unused image file", which directly violate our existing RC. Moreover, it can support these formats: PNG, JPG, GIF, and BMP.

Here is the better comparison. I encoded an audio file with embedded image to OGG with Q6.

As you can see, the actual audio stream actually adheres to RC for OGG at 203 kbps, but due to the presence of embedded image, the bitrate is misinformed to 226 kbps, which is not quite correct if you try to summarize the bitrate. This, however, doesn't affect MP3 file's bitrate as they're mostly rendered in constant bitrate, but still have their size increased by certain amount.
clayton

Ryu Sei wrote:

There must not be any unused files or 0-byte files in the beatmap's folder. 0-byte files prevent other files in a beatmap's folder from properly uploading. Automatically generated thumbs.db files are the only exceptions.

An embedded file can be treated as an "unused image file"
I feel like it should be obvious that the word "file" in that rule is referring to literal files in a filesystem...
RandomeLoL
I'm with clayton here that this can be a good resource to have in the article's they mentioned. Yes, this is something that has it's value to know. But it's outside of the RC scope as mentioned before.

Also the rule quoted doesn't account for embedded images. These aren't recognized by file systems as independent files.
Topic Starter
Ryu Sei
Perhaps you're right. Maybe we can add it to the wiki resources in regards of trimming file size (blanking metadata, removing embedded images, etc.). I can't contribute to wiki, so it would be great if this is forwarded to the wiki admins.
Okoayu

Hivie wrote:

i disagree with enforcing this because it's an overhead that's not worth the negligible amount of benefits (saving ~0.1 mb). it's additionally gonna be an additional annoying check for BNs where they already have enough annoying technical checks to deal with, not to mention how it's unreasonable to expect mappers to keep up with all kinds of third party tools to use.

all this overhead is simply not worth it for such a minor difference.
My original MP3 for beatmapsets/1294563#osu/2686289 had a 4096 x 4096 album cover included in it which added 5mb in filesize

We changed it post rank because the metadata of the audio file accidentally also included a bunch of data that i'd rather not mention

I think this is worth having if we have automatic tooling to check for it
clayton
would you have considered the attached album cover worth the effort to remove if it weren't as large as 5mb? I feel like the side discussion in this thread about the assumed file size savings from removing images is not really relevant, because file size is a more broad concern and opportunities to easily save as much as e.g. 5mb should be taken regardless of whether it comes from an album cover or not.

the only issue pointed out in this thread that is uniquely caused by other data in audio files is the mislabeled bitrate thing in OP, but seeing as it hasn't been mentioned again I don't think it is considered important
Ymir

Okoratu wrote:

I think this is worth having if we have automatic tooling to check for it
Is a 1MB+ difference common enough to make (or use) an automatic tool?
Topic Starter
Ryu Sei

Okoratu wrote:

My original MP3 for beatmapsets/1294563#osu/2686289 had a 4096 x 4096 album cover included in it which added 5mb in filesize

We changed it post rank because the metadata of the audio file accidentally also included a bunch of data that i'd rather not mention

I think this is worth having if we have automatic tooling to check for it
I don't think there is a tool to detect such, but as I mentioned before, the foolproof way to do that regardless it having the image or not is simply re-encoding it to the same format using Audacity, since it ignores the embedded images. Using ffmpeg will preserve the image without extra arguments.

The re-encoding issue might happen though, such as reduced audio quality or increased offset...
Leviathan
i get what youre trying to say but i dont think it should be enforced lol (really i think the same for the bitrate but thats definitely not going to change for good reason)
at most this should be enforced for ogg files seeing as on a clean windows installation you cant see the image in explorer however no one really looks at the metadata for mp3 files in explorer anyway let alone images

also people have inserted their own custom images into mp3 files for ranked maps before and not letting people change that is kinda sad imo
Okoayu
discussion here is kinda dead, moved it onto the rewrite radar at the very least (we already talked about the part that made me post in here)
Please sign in to reply.

New reply