WebM?

"Bill in Co" wrote in
m:

No, both. I know the difference too. WMV does use VFR.
Not sure about h.264 though.

But only as an *option*. My MP4 and WMV files (like most of my video
files) use a constant frame rate. And I think it's better that way. :-)


So do I. Btw, I wasn't saying that WVM couldn't do it, just that it uses (as
in can use) VFR. I didn't know if it had both options, I just knew that when
I looked into transcoding the files that gave me trouble, I found that they
were VFR because no CFR was given in the file details in MPClassic, and when
I went to Doom9 for info about transcoding them, I learned that this was
right.

I suspect that mostly they work for you because of the CFR.

*plays Hendrix: I hear my train a'coming...*

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

No, both. I know the difference too. WMV does use VFR.
Not sure about h.264 though.

But only as an *option*. My MP4 and WMV files (like most of my video
files) use a constant frame rate. And I think it's better that way.
:-)


So do I. Btw, I wasn't saying that WVM couldn't do it, just that it uses
(as
in can use) VFR. I didn't know if it had both options, I just knew that
when
I looked into transcoding the files that gave me trouble, I found that
they
were VFR because no CFR was given in the file details in MPClassic, and
when
I went to Doom9 for info about transcoding them, I learned that this was
right.

I suspect that mostly they work for you because of the CFR.

*plays Hendrix: I hear my train a'coming...*

LOL.

Use MediaInfo (from the Sourceforge site), and I think you can get more
detailed and accurate info on the video and audio tracks (and is also nice
for audio files).

I think using VFR is asking for trouble. Ditto on using VBR in the audio
track of a video file. (I like things simple and troublefree too).

The only point I "cave in on" is when transcoding to MP4(h264) or WMV, I'll
often choose the "constant quantizer" mode (where you pick a number between
1 and 50 for the quantizer value QF).

That QF value is a tradeoff between quality and filesize, with lower QF
values giving better quality (less compression, but using higher nominal
bitrates, and larger filesizes)

XMediaRecode (freebie) works nicely for video conversions. I typically
have found a QF of 18-25 to be most useful.

"Bill in Co" wrote in
m:

I think using VFR is asking for trouble. Ditto on using VBR in the audio
track of a video file. (I like things simple and troublefree too).


Weirdly enough I actually do that. VBR in movies audio. It seems to work ok.
Don't forget, not same as VFR... Once decoded the 'frame rate' of audio, the
sample rate, stays constant even with VBR, and VBR in video is a standard
anyway, more bits allocated for fast motion, etc. All that can cause spikes
and desync too, but not nearly so much. I think the reason is that once you
render to raw video stream the flow better HAD be steady because there's so
much of it. I imagine VFR partly relies on graphics hardware acceleration to
take the extra load. So it fails abysmally if it has to share the CPU with
the main decode process also peaking at that point on fast motion.

Anything like actual VFR in audio is EXTREMELY rare. I had to try Echo's
later WDM driver with later hardware than I like, to get exact sample rates
for laser scan testing (18,000 Hz, 30,000 Hz, 40,000 Hz, not typical at all
of audio), and I still couldn't modulate them. VFR video tries to do all of
that, no wonder it's so hard to transcode well to XviD, it's like trying to
map out irrational numbers on an integer scale! I got mencoder to do a good
job of it though. Vdub wasn't so good, or I missed something in that, I don't
know. Even with mencoder I can see speed jitter in what should be smooth
motions like passing cars, but it is at least watchable and light on demand
afterwards.

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

I think using VFR is asking for trouble. Ditto on using VBR in the audio
track of a video file. (I like things simple and troublefree too).


Weirdly enough I actually do that. VBR in movies audio. It seems to work
ok.
Don't forget, not same as VFR... Once decoded the 'frame rate' of audio,
the
sample rate, stays constant even with VBR, and VBR in video is a standard
anyway, more bits allocated for fast motion, etc. All that can cause
spikes
and desync too, but not nearly so much. I think the reason is that once
you
render to raw video stream the flow better HAD be steady because there's
so
much of it. I imagine VFR partly relies on graphics hardware acceleration
to
take the extra load. So it fails abysmally if it has to share the CPU with
the main decode process also peaking at that point on fast motion.

I've just read some comments (perhaps on VideoHelp.com) where there have
been sync issues reported when using VBR for the audio tracks in a video
file. IOW, where the file is encoded and the A/V drifts out of sync, one
factor that can cause that in some cases is using VBR for the audio track,
and the consequent recommendation is to use CBR for the audio track. And
there's really no good reason not to use CBR here, since the audio track is
so small in size in comparison to the video track, so it really doens't
affect the video's filesize that much.

Anything like actual VFR in audio is EXTREMELY rare.

I didn't think there was such a thing. If there is, I sure wouldn't use it
for what I'm doing (restoring or transcoding audio). It's just asking for
trouble (one more thing to go wrong, either in encoding or decoding)

My audio work is always either encoded at 48K (as needed for DVD tracks),
44.1K (the standard), or 22.05K (this one can be useful for oldtime radio
broadcasts that I can highly compress, like down to 64 kbps in mp3 or wma).

I had to try Echo's
later WDM driver with later hardware than I like, to get exact sample
rates
for laser scan testing (18,000 Hz, 30,000 Hz, 40,000 Hz, not typical at
all
of audio), and I still couldn't modulate them. VFR video tries to do all
of
that, no wonder it's so hard to transcode well to XviD, it's like trying
to
map out irrational numbers on an integer scale! I got mencoder to do a
good
job of it though. Vdub wasn't so good, or I missed something in that, I
don't
know. Even with mencoder I can see speed jitter in what should be smooth
motions like passing cars, but it is at least watchable and light on
demand
afterwards.

"Bill in Co" wrote in
m:

I've just read some comments (perhaps on VideoHelp.com) where there have
been sync issues reported when using VBR for the audio tracks in a video
file. IOW, where the file is encoded and the A/V drifts out of sync, one
factor that can cause that in some cases is using VBR for the audio track,
and the consequent recommendation is to use CBR for the audio track.

I've read that point many times, but I never had VBR audio desync on me. it
is definitely worth doing too, the extra bits available to video can make all
the difference. I really HATE desync. If ti happened in my own encodes I'd
NEVER stand for it. Trust me, that 'problem' posted all over the net is
highly overstated. Maybe there was some context I don't know, but if you use
Gordian Knot with mostly default settings, it ought to be as effective. Some
rips need correction for sync anyway, but that;s anot a VBR thing. With
either CBR or VBR, if I correct that, it stays corrected throughout the
duration, and is ok when seeking too.


For the radio shows, try this:
LAME --preset 80 --resample 24 --lowpass 11
Humour me. Ignore the way that looks, and have a go. I know that 80 is more
than 64, but it's also a damn sight less than 128! This one works well on
stereo. (OTR is usually mono..) Let me know how it goes.

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

I've just read some comments (perhaps on VideoHelp.com) where there have
been sync issues reported when using VBR for the audio tracks in a video
file. IOW, where the file is encoded and the A/V drifts out of sync, one
factor that can cause that in some cases is using VBR for the audio
track,
and the consequent recommendation is to use CBR for the audio track.

I've read that point many times, but I never had VBR audio desync on me.
it
is definitely worth doing too, the extra bits available to video can make
all
the difference. I really HATE desync. If it happened in my own encodes I'd
NEVER stand for it. Trust me, that 'problem' posted all over the net is
highly overstated. Maybe there was some context I don't know, but if you
use
Gordian Knot with mostly default settings, it ought to be as effective.
Some
rips need correction for sync anyway, but that;s anot a VBR thing. With
either CBR or VBR, if I correct that, it stays corrected throughout the
duration, and is ok when seeking too.


For the radio shows, try this:
LAME --preset 80 --resample 24 --lowpass 11
Humour me. Ignore the way that looks, and have a go. I know that 80 is
more
than 64, but it's also a damn sight less than 128! This one works well on
stereo. (OTR is usually mono..) Let me know how it goes.

I'll keep it in mind next time I'm processing OTR. :-)

"Bill in Co" wrote in
m:

For the radio shows, try this:
LAME --preset 80 --resample 24 --lowpass 11
Humour me. Ignore the way that looks, and have a go. I know that 80 is
more
than 64, but it's also a damn sight less than 128! This one works well on
stereo. (OTR is usually mono..) Let me know how it goes.

I'll keep it in mind next time I'm processing OTR. :-)



I used it on new stuff. I think it works well for a mix of speech, soundtrack
and music. Aren't you curious to see if it really does?

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

For the radio shows, try this:
LAME --preset 80 --resample 24 --lowpass 11
Humour me. Ignore the way that looks, and have a go. I know that 80 is
more
than 64, but it's also a damn sight less than 128! This one works well
on
stereo. (OTR is usually mono..) Let me know how it goes.

I'll keep it in mind next time I'm processing OTR. :-)



I used it on new stuff. I think it works well for a mix of speech,
soundtrack
and music. Aren't you curious to see if it really does?

Well, it's been awhile since I've needed to work on any OTR or other such
files. But I agree it would be a nice step up from the 22K, 64 kbps!
That's pretty obvious just by looking at it.

One of the driving factors for me was going as small as I could to save disk
space (esp. for storage on a portable mp3 player). If you want to try some
tests, you should try listening to a joint stereo, 64 kbps (22K sampling),
in both mp3 and wma formats. I think you'll notice a difference. :-) (if
not, go lower and see)
By wma, I mean wma8 (or 9) (wma7 is too old).

I'll be gone for a couple of days (looking forward to a small trip),
although I'm not looking forward to flying. The days of air travel being
fun went out long ago :-(

"Bill in Co" wrote in
m:

One of the driving factors for me was going as small as I could to save
disk space (esp. for storage on a portable mp3 player). If you want to
try some tests, you should try listening to a joint stereo, 64 kbps (22K
sampling), in both mp3 and wma formats. I think you'll notice a
difference. :-) (if not, go lower and see)
By wma, I mean wma8 (or 9) (wma7 is too old).


I'd never use a windows format. Too specific, and it goes against the idea of
staying with the widest compatible formats.

Small size was what I wanted, and LAME --preset 80 --resample 24 --lowpass 11
works because the LAME standard presets are pretty good already but do things
a bit differently. If you use the base --preset 80 it defaults to a higher
filter cutoff, ends up with a nasty graininess in the low midrange that makes
radio shows sound like they were recorded on slightly chewed magnetic tape.
There's no magic to my choice of settings, the basis is to drop the filter
slightly to settings LAME chooses for a lower average bitrate anyway. The
extra bits get allocated to reducing the LF artifacting, so the signal ia
MUCH cleaner despite the low cutoff. If the cutoff seems a tad too muffling,
boost the HF at around 12 to 14 KHz with about 6 to 12 dB using any gentle
filter as found in most equalisers. The result is similar to high quality FM,
which is about as good as a radio broadcast ever got before digital systems.

There's another way to further compress this too, if you need it smaller
still. Drop the volume by 6 or 12 dB. There's 1 bit saved per 6dB dropped.
This allows some subtletly. Calculate what the likely required bitrate
average will be for the resulting signal, set that directly as a --preset
value. When the output is encoded to file, use a lossless tool like
MP3DirectCut to boost the volume by the same amount using the level scale
values (all the same in each frame). The result should be a smaller file than
normal, the price of the shrinkage being a louder noise floor. If LAME ro
some other encoder is dithering that npoise and using noise shaping, the odds
are you can push this method and still have a listenable file because shaped
noise or even a constant noise floor is usually far less objectionable that
pitched or percussive artifacts usually found in highly compressed MP3's.

I haven't tried that test but I intend to sometime. I know that WAVpack's
lossy format is very good with noise shaping, and BitSave (that experimental
tool I linked to several posts back) does amazing things with as few as 8
bits. 12 should sound excellent on most things that use modest dynamic range
to start with. If the source is clean to start with it should work. Maybe
even if it's not, any existing noise might make masking easier.

I'll be gone for a couple of days (looking forward to a small trip),
although I'm not looking forward to flying. The days of air travel
being fun went out long ago :-(


I've never done it.. whenever I've had money there's always been something I
wanted to do more. I think Isaac Asimov managed to never fly in his life.