Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Megaphone file sizes make me look into state of VBR (Read 3359 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Megaphone file sizes make me look into state of VBR

Maybe this anger is misplaced but I have one podcaster who treats it as an archive and uploads hour-long 256kpbs for talk. 119MB for 1:05. Seems Soundcloud seems to have VBR podcasts consistently. But here we are in 2023, and I found this explanation

Quote
There are ways to avoid this. Long, long ago, folks created a number of standards that allow metadata to be embedded in the MP3, allowing decoders to figure out where to seek to. I could write more about this, but it’s a moot point because virtually nobody implements the standard.
https://mattbasta.medium.com/vbr-is-it-actually-as-bad-as-they-say-9ee55ff477de
So ok, that's from 2017. Maybe the sites tell people how to do that.

Quote
Choose constant bitrate (CBR) over variable bitrate (VBR) for recording a podcast.
https://www.androidauthority.com/how-to-start-podcast-on-spotify-for-free-3310680/

Ya so it's just a non-starter. Is faster Internet going to cement this problem into an ossified stick in the mud? Just wish my podcaster wouldn't have to have VBR do his dirty work though and go with 128 which is why I wrote this post rather than start a war with someone's regimen.

Re: Megaphone file sizes make me look into state of VBR

Reply #1 –
Lossless conversion from CBR to VBR is possible. You can give it a try and see if any of the problems mentioned in that article will affect you.

You can also try muxing the resulting VBR MP3 into a container with proper seek metadata, such as MP4 or Matroska.

Re: Megaphone file sizes make me look into state of VBR

Reply #2 –
Man, of all the arguments I've seen made, "Don't use VBR when encoding MP3s because mp2 decoders aren't required to support VBR" is one of them.

Someone correct me if I'm wrong, but mp2 decoders also aren't required to support decoding mp3 at all?

EDIT: It wouldn't surprise me if certain hardware mp3 players also, say, had a bug where they didn't properly handle mono mp3s (sending the one channel to both channels) and either played them only on one channel or played one sample in one channel, the next in the other channel, and so on, resulting in a weird chipmunked pseudo-stereo output.  Yet nobody argues mono mp3s are bad because of it.

Re: Megaphone file sizes make me look into state of VBR

Reply #3 –
Also, aren't most post-mp3 codecs at least a little vbr by default?

Re: Megaphone file sizes make me look into state of VBR

Reply #4 –
When I say "my podcaster", I'm not saying I'm a producer, I'm just looking for advice on what podcasters can do on a self-help basis.
Quote from: Octocontrabass on

You can also try muxing the resulting VBR MP3 into a container with proper seek metadata, such as MP4 or Matroska.
Also, I picked only the source that I have, not very interested in mp2, mono, mp4 or lossless vbr but at least with proper seek metadata, this commenter is on the right track. But the fact that now there are 2 sources now who do not know immediately how to fix the biggest problem with vbr for podcasts, the seeking problem, within mp3, like it said on medium says something.

Re: Megaphone file sizes make me look into state of VBR

Reply #5 –
Quote from: balloonguy on
But the fact that now there are 2 sources now who do not know immediately how to fix the biggest problem with vbr for podcasts, the seeking problem, within mp3, like it said on medium says something.
Is it possible that "something" that it says is that those two people, rather than searching for a solution that would allow them to use VBR, went the easy route and just use CBR instead?

Re: Megaphone file sizes make me look into state of VBR

Reply #6 –
Quote from: balloonguy on
the seeking problem, within mp3
MP3 wasn't designed to be seekable in the first place. If you wanted that, you were supposed to put it in a container, and the MPEG-1 standard defined MPEG-PS for that purpose. Newer audio codecs require a container to function at all - for example, you can't decode a raw AAC bitstream the way you can with MP3 - and the container ensures accurate seeking for those codecs.

There's one popular hack for VBR metadata in raw MP3, the Xing header, but it only has 100 seek points specified in units of 1/256 the file size. That's not nearly precise enough for accurate seeking in an hour-long podcast even if your player supports it.

Re: Megaphone file sizes make me look into state of VBR

Reply #7 –
I created a local VBR 256k file and both firefox and Edge seek without issue.

Re: Megaphone file sizes make me look into state of VBR

Reply #8 –
Quote from: binaryhermit on
Quote from: balloonguy on
But the fact that now there are 2 sources now who do not know immediately how to fix the biggest problem with vbr for podcasts, the seeking problem, within mp3, like it said on medium says something.
Is it possible that "something" that it says is that those two people, rather than searching for a solution that would allow them to use VBR, went the easy route and just use CBR instead?

Common for inexperienced folk to use top cbr settings like 256 or 320 . Even for silence.

Re: Megaphone file sizes make me look into state of VBR

Reply #9 –
Quote from: balloonguy on
Maybe this anger is misplaced but I have one podcaster who treats it as an archive and uploads hour-long 256kpbs for talk. 119MB for 1:05. Seems Soundcloud seems to have VBR podcasts consistently.

Your general concern aside:
Soundcloud streams as 128 CBR. Knowing the upload is VBR, actually listening to the CBR while whining over the V, doesn't that sound like classical audiophoolery?

Getting an extra cloud backup by uploading in a format good enough for later transcoding, it doesn't appear that stupid to me. Of course, you can do better than the 1.6 GB uploaded in 32-bit WAVE at https://soundcloud.com/cvltnation/cvlt-cast-episode-one-doom-2016 (... and beware what might be a very nasty volume spike, I RG scanned it but didn't check thoroughly). Sure upload your music direct from your DAW if you like, but this is a podcast.
Still streams as MP3 at 128 CBR though. And it isn't because it is a "non-mp3" format: https://soundcloud.com/cvltnation/cvlt-cast-2-bolzer is 320 CBR as file, streamed at 128 CBR. Yes I am logged in.

Re: Megaphone file sizes make me look into state of VBR

Reply #10 –
Quote from: Octocontrabass on
Quote from: balloonguy on
the seeking problem, within mp3
MP3 wasn't designed to be seekable in the first place. If you wanted that, you were supposed to put it in a container, and the MPEG-1 standard defined MPEG-PS for that purpose. Newer audio codecs require a container to function at all - for example, you can't decode a raw AAC bitstream the way you can with MP3 - and the container ensures accurate seeking for those codecs.

There's one popular hack for VBR metadata in raw MP3, the Xing header, but it only has 100 seek points specified in units of 1/256 the file size. That's not nearly precise enough for accurate seeking in an hour-long podcast even if your player supports it.
Big thank you! Hope I had at least provided the inspiration so this message can get out. O:)
So, it is a short-file-only solution, which undercuts the purpose of seeking, that's why few people use it. On top of which, all we get is a German Wikipedia.
https://de.wikipedia.org/wiki/Xing-Header
and a site in English, with prolly similar info, still pointing out the failures of mp3 seeking, which points to what for me is a dead link
https://second.wiki/wiki/xing-header
This thread gives me clarity on the situation.
And Porcus, the audio-on-demand attachment/file link when viewing the rss feed item, for which I'm also given a separate general URL which takes me to soundcloud's front-end, but once again for the former, is located in the following
Code: [Select]
feeds.soundcloud.com/stream/<mp3file>
While VBR can be high quality to upload it's also, at least outside of mp3, ubiquitous as the end result. Though perhaps I should've said I only saw it on 1 of my podcast subscriptions, of dozens, which happens to be the only 1 to use soundcloud. May have given the wrong impression by saying "Soundcloud" and not "Soundcloud for this one podcast" inadvertently through my own impression that VBR could be flawlessly done in mp3.

Re: Megaphone file sizes make me look into state of VBR

Reply #11 –
If you search Xing Header within LAME, you will find all the information that you need. Given the age of mp3 it's amazing how it continues to thrive and survive. There are better solutions out there, but it's performance is nowhere near bad enough for it to die in my lifetime, at least. (But I am quite aged!)  ;D

Re: Megaphone file sizes make me look into state of VBR

Reply #12 –
I am glad it's downloadable. To cover SEO. Link is what I got for "xing header wikipedia", which I thought was a decent stab to find the key feature. On LAME's site, where it's unintegrated in LAME itself and does not use or support it, but on the offchance someone would go to them for that specific solution in a different encoder, sacrificing file size, they link to the mp3 sphere with a description that does not mention the key feature, leading no hypothetical use out of it without cross-referencing sites to get both the download and the info.
Quote
Other MP3 Encoders: Xing MP3 encoder Good quality and very fast encoder. It is now the MP3 encoder used in Real Player, and has been recently released under an Open Source license (the speed tweaks are still limited to Windows though, because they are written in MASM)
Quote
The Xing MP3 encoder was created around 1995, seemingly from scratch, by the Xing Technology Corporation with a primary goal in mind: creating a very fast encoder.

And it delivers! It is much faster than other encoders in benchmark tests, even compared to famously fast encoders such as Musepack, Gogo and Ogg Vorbis Lancer. These speed gains are obtained mostly with heavy usage of x86 assembly code (which, in this case, is unfortunately limited to the Windows platform).

What about quality? Surprisingly, the quality is quite good! Of course not on par with LAME, but if you are in a hurry, Xing can be a good choice as it is several times faster.

Xing also created audio players and a CD Ripper.

Xing Technology was acquired by RealNetworks in the early 2000s (but you can still check their web site at the Internet Archive, here), and the MP3 encoder was renamed to Helix MP3 Encoder. Then, in 2005, they released the sources under an open source license. It seems they closed the sources again, but here you can find compiles of their encoder made while they were still open, as well as the source code.

So I guess I was also wrong, with VBR in LAME, which is the no-brainer option with today's CPUs, would have people get 0 seeking benefits.

Re: Megaphone file sizes make me look into state of VBR

Reply #13 –
Quote from: balloonguy on
unintegrated in LAME itself and does not use or support it
What's not integrated? By default, LAME adds a Xing header on everything except gapless MP3s. Even CBR MP3s get a header, although it's not exactly a Xing header since CBR doesn't need seek metadata.

Re: Megaphone file sizes make me look into state of VBR

Reply #14 –
I'm really surprised at how much of the podcasting world is still stuck on MP3. AAC works fine and solves this VBR/seeking problem entirely, especially when combined with the HTTP Range requests so clients can request the exact chunks they need, as needed.

I don't really see the benefit of encoding to MP3 in almost-2024. Most people listen to podcasts via their phone, your phone has an AAC decoder, and MP4 files solve that seeking problem by specifying how large each and every frame of audio is. Just figure out how many frames you want to seek forward by, sum up the bytes from your sample size table, and off you go.
 

Re: Megaphone file sizes make me look into state of VBR

Reply #15 –
Quote from: Octocontrabass on
Quote from: balloonguy on
unintegrated in LAME itself and does not use or support it
What's not integrated? By default, LAME adds a Xing header on everything except gapless MP3s. Even CBR MP3s get a header, although it's not exactly a Xing header since CBR doesn't need seek metadata.

Quote from: john33 on
If you search Xing Header within LAME, you will find all the information that you need. Given the age of mp3 it's amazing how it continues to thrive and survive. There are better solutions out there, but it's performance is nowhere near bad enough for it to die in my lifetime, at least. (But I am quite aged!)  ;D

Not to sound disingenuous but in my post I said "To cover SEO." and then at the end "would be, with their information, a no-brainer" I took his statement "within LAME", went to LAME's site (mind you from a search for Xing header wikipedia, and concluded that Xing and LAME were irreconcilable. I was clicking around and eventually came to my own conclusion, because I'm here writing a big thread, that you are ultimately correct.

Also I looked at this page.
Quote
The ‘lame’ (or xing) header provides extra information about the mp3 that is useful to players and encoders but not officially part of the mp3 specification. Variable bit rate mp3s, for example, use this header.
For more details see here
I clicked see here and found out that both are in there. It more granularly could have said The LAME and Xing header, which create both the LAME encoded and the Xing encoded VBR mp3s use this header

Quote from: jprjr on
I'm really surprised at how much of the podcasting world is still stuck on MP3. AAC works fine and solves this VBR/seeking problem entirely, especially when combined with the HTTP Range requests so clients can request the exact chunks they need, as needed.

I don't really see the benefit of encoding to MP3 in almost-2024. Most people listen to podcasts via their phone, your phone has an AAC decoder, and MP4 files solve that seeking problem by specifying how large each and every frame of audio is. Just figure out how many frames you want to seek forward by, sum up the bytes from your sample size table, and off you go.
LAME, Xing law firm VBR MP3 right now has basically this solution but at lower resolution, I would argue they have an opportunity to make it even better than AAC because they can choose, when encoding an mp3, to scale to a seeking resolution like picking the quality.



Re: Megaphone file sizes make me look into state of VBR

Reply #16 –
Quote from: balloonguy on
I would argue they have an opportunity to make it even better than AAC
AAC doesn't have seek metadata. Are you thinking of a container format such as MP4?

Quote from: balloonguy on
because they can choose, when encoding an mp3, to scale to a seeking resolution like picking the quality.
The Xing header isn't flexible enough to do that. Better seek metadata would require a new header, and nobody wants a new header because players wouldn't support it. If you want better seek metadata for MP3, you can put your MP3 into a container like MP4, and many players already support that.

Re: Megaphone file sizes make me look into state of VBR

Reply #17 –
Yes mp4 I mean for this. But you keep asking why do I want to tell which raw format is underneath at a glance, for which fb2k created color coding and beautiful logos for the formats, this just seems like a preposterous question to ask on a scientific discussion page. So for the same reason for a file with the same name I don't want to convert from a lossy when I have a lossless, I don't want to convert from a certain type of lossy when I have another type at the ready.
I came across someone saying that with software, there's no absolute necessity for uniform lengths. However, if the file takes too long to sort in the OS that way I assume, how about an ID2 tag which is loaded also at the start of the file on-demand as variable up to 256MB, which can be any data because webp now exists and loads fine?

Re: Megaphone file sizes make me look into state of VBR

Reply #18 –
Quote from: balloonguy on
I don't want to convert from a certain type of lossy when I have another type at the ready.
Multiplexing MP3 into MP4 is lossless (for the audio).

Quote from: balloonguy on
I came across someone saying that with software, there's no absolute necessity for uniform lengths.
Which lengths are you talking about?

Quote from: balloonguy on
However, if the file takes too long to sort in the OS that way I assume, how about an ID2 tag which is loaded also at the start of the file on-demand as variable up to 256MB, which can be any data because webp now exists and loads fine?
ID3v2.4 already allows seek metadata, but I've never seen anyone use it. I don't think any players support it.

Re: Megaphone file sizes make me look into state of VBR

Reply #19 –
Now I detect disingenuousness. You know the difference between containers and coding standards for lossy digital audio compression, but now are using mp4 in place of aac. You also acknowledge a way forward for mp3's coding standard for lossy digital audio compression, which was the only point I was making.

PS: I don't personally use mp4s, I use m4as, but the premise with aac seems to remain intact

Re: Megaphone file sizes make me look into state of VBR

Reply #20 –
Quote from: balloonguy on
You know the difference between containers and coding standards for lossy digital audio compression, but now are using mp4 in place of aac.
Huh? It sounds like you're doing that, not me. MP4 supports several different audio codecs, including MP3, ALAC, Opus, FLAC, and of course AAC. Nothing says MP4 can only contain AAC audio.

Quote from: balloonguy on
You also acknowledge a way forward for mp3's coding standard for lossy digital audio compression, which was the only point I was making.
It's not really a way forward if nobody will go that way.

Quote from: balloonguy on
PS: I don't personally use mp4s, I use m4as, but the premise with aac seems to remain intact
The only difference between MP4 and M4A is the file name. Both are completely ordinary MP4. (Although some players might be surprised if your "M4A" MP4 file contains something other than AAC audio.)