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: nominal bitrate info tweaking. (Read 10194 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

nominal bitrate info tweaking.

Hi:

I have a little, cheapo 256 meg flash player (a S1 type player), wich happens to play vorbis files.
This is good for me since it allows me to squeeze a lot of music in it.
the player can show the files's bitrate with some "standard" scales, like 64k, 80k, 96k, 112k... I used a firmware editor available arround the net and all those tags have their own discrete bitmap... there's no lower one than for 64k. Coincidentally the player will refuse to play files with a nominal bitrate lower than that, although it won't have a problem if the real bitrate is actually lower. In some cases it even starts to play for a splice second before it shows a "format error" message.

I think the player is capable of playing files with just about any bitrate and the limitation is actually a bug, out of lazyness most probably. There must be a limit of course, but it is NOT 64k. Also there will be stutter when bitrate is too high, like 400 or so xD, but there's no point for that in a shitty player like this.

So. I don't know the real importance of the nominal bitrate information bit. To me it seems merely informative, and if it is so, it would be nice to have some tool to tweak it for these special cases where you have such a dumb player.

Can someone help me?

nominal bitrate info tweaking.

Reply #1 –
Quote from: radorn on
So. I don't know the real importance of the nominal bitrate information bit. To me it seems merely informative, and if it is so, it would be nice to have some tool to tweak it for these special cases where you have such a dumb player.

Can someone help me?


As you guessed it is merely informative, although some players (even a few software ones like VideoLan until just recently) accidentally use it as an authoritative number.

In an Ogg Vorbis I file, the bitrate hint is bytes 45 through 56.  The nominal bitrate hint is bytes 49-52 and the encoding is little endian.  So, inserting '00 f4 01 00' for bytes 49-52 will set the nominal bitrate hint to 128kbps.

Monty

nominal bitrate info tweaking.

Reply #2 –
Whoa, my first post and I get a reply for Vorbis' creator himself

Thanks for the reply.

I guess I'm stuck with manual hex editing then, because I can't code a program for that (or anything for that matter).
Well, I actually coded a pretty neat ATF title-formatting rule for winamp and foobar but that doesn't count, does it?

It would be nice to have that functionality on encoders, and also in the "Utils" item in foobar's context menu.
Guess I should bug someone to do it for me, but I feel bad doing that  haha

EDIT1: removed quotes

EDIT2: I have found that in my files the offset is 48-51 rather than 49-42, I use aotuv r1. got me confused until I figured that. I guess you start counting at 1 rather than 0.

nominal bitrate info tweaking.

Reply #3 –
Quote from: radorn on
EDIT2: I have found that in my files the offset is 48-51 rather than 49-42, I use aotuv r1. got me confused until I figured that. I guess you start counting at 1 rather than 0.


I was counting from one, sorry.

Monty

nominal bitrate info tweaking.

Reply #4 –
I've been trying with many files, even made test files with different encoders, but no matter what I try: Every time I edit that offset I render the file corrupt in the eyes of every player I have fed it to, both hardware and software based. No matter what value I put in, 64000, 128000, 256000 (properly converted to 32bit word little endian hex), all result in a corrupted file.



EDIT: Even oggdec and oggdrop say it's not a good file

C:\Documents and Settings\Administrador\Escritorio>oggdec x.ogg


OggDec v1.9.3 (libVorbis 1.1.2) Compiled on: Oct 25 2006

Input x.ogg does not appear to be an Ogg bitstream.


********** Done decoding all input files. **********

I'm screwed

nominal bitrate info tweaking.

Reply #5 –
I wonder what your motives are for circumventing this bug in your player: ogg vorbis tends to sound rather questionable below 64kbit nominal. The 64-128kbit range is vorbis's "sweet spot" and where it shines the most - above and below that it doesn t offer significant advantages over other popular codecs.
I am arrogant and I can afford it because I deliver.

nominal bitrate info tweaking.

Reply #6 –
Quote from: Lyx on
I wonder what your motives are for circumventing this bug in your player: ogg vorbis tends to sound rather questionable below 64kbit nominal. The 64-128kbit range is vorbis's "sweet spot" and where it shines the most - above and below that it doesn t offer significant advantages over other popular codecs.


well, that's true for 44.1khz 16bit stereo, so called CD-like.

I'm a strange guy and listen to music wich is originally encoded in lower formats, like 32000 and 22050, and also in mono, so bitrate (including nominal) becomes lower than 64 at q0 or so.
I could raise the bit rate until nominal would become 64. But I don't want that, for several reasons, including that I don't feel like working so much for some encodes that are just made ad-hoc for listening on the go rather than an elaborate mastering process for archiving, wich I do at -q5 or higher, mind you, or -q4 for not-so important stuff.

nominal bitrate info tweaking.

Reply #7 –
Thanks for your explanation. It's always interesting to learn about unusual but reasonable usage-scenarios : )
I am arrogant and I can afford it because I deliver.

nominal bitrate info tweaking.

Reply #8 –
Quote from: radorn on
I've been trying with many files, even made test files with different encoders, but no matter what I try: Every time I edit that offset I render the file corrupt in the eyes of every player I have fed it to, both hardware and software based. No matter what value I put in, 64000, 128000, 256000 (properly converted to 32bit word little endian hex), all result in a corrupted file.


Oh, ha, I forgot to mention the tiny little indispensible fact that the page will need to be re-checksummed after modification....  So yeah, a hex editor alone isn't enough.

It wouldn't be that hard to do with libogg though (read the first page and packet, alter the bytes, re-write the packet/page, which will take care of computing a new checksum)
 

nominal bitrate info tweaking.

Reply #9 –
Quote from: Lyx on
Thanks for your explanation. It's always interesting to learn about unusual but reasonable usage-scenarios : )


hehe, ok


Quote from: xiphmont on
Oh, ha, I forgot to mention the tiny little indispensible fact that the page will need to be re-checksummed after modification....  So yeah, a hex editor alone isn't enough.


I was fearing that, oh well.
I will try to find some "fixer" tool, for a (very slim) chance of it recalculating that checksum.
At least that would allow me to see if the trick does work and make my files playable.
Not that it will be very useful in that way (encode > hex edit > fix > copy to player) but at least it would "prove the concept"

I'll definitelly bug someone arround to implement this on, say, foobar