Audio editing and converting

Bill in Co wrote:

No, I did see all 15 parts, and they appeared to be ok from the
listings (and with equal reported lengths), but when decoded and
combined into one wav file, it came out to be only 29 seconds long
when played, and it wasn't contiguous.

I would suspect the problem lies with the decoder. I'm guessing you used
OE...did you properly arrange the files? If yes, then the best I can
suggest is to use another decoder.

--

dadiOH
____________________________

dadiOH's dandies v3.06...
....a help file of info about MP3s, recording from
LP/cassette and tips & tricks on this and that.
Get it at http://mysite.verizon.net/xico

dadiOH wrote:
Bill in Co wrote:

No, I did see all 15 parts, and they appeared to be ok from the
listings (and with equal reported lengths), but when decoded and
combined into one wav file, it came out to be only 29 seconds long
when played, and it wasn't contiguous.

I would suspect the problem lies with the decoder. I'm guessing you used
OE...did you properly arrange the files? If yes, then the best I can
suggest is to use another decoder.

No, I gave up on OE for that (I did try it however and it was a futile
exercise, at least for me). So I used Xananews, which has worked ok for me
before. And I did it twice just to be sure.

What was fascinating about it was that after decoding and combining the 15
equal length segments, the result was a playable, 29 second file, but with
skipped over portions (or sections) of the actual content. I would have
expected otherwise (e.g: a bad, unplayable, file under such a situation).

More on very low bitrate file conversion tests, in reference to AAC, MP3,
and WMA formats:

By very low bitrates, I'm talking about stereo (2 channels) being encoded
down to 32 kbps, 22 kHz, using either stereo or joint stereo in the
encoding. This seems to be about as low as we can go with any possibility
of decent results, and it's pretty challenging to get there faithfully, and
even then it's only useful for stuff like old radio broadcasts. (And if we
encoded to mono, we could presumably cut the bitrate in half, since only one
channel would need to be processed, of course).

AAC notes:
I had some time and did some other experiments with encoding, and found out
that AAC can also do a pretty good job at these very low bitrates, like WMA,
but alas, not all portable mp3 players can play it. Plus AAC is a bit
tricky, like you apparently need to force LC-AAC compression at these low
bitrates for best compatibility across players, or you will "lose" the highs
due to improper decoding on some AAC players (even including QuickTime, of
all things!).

MP3 notes:
I also found that apparently the FhG mp3 encoder can work better (have less
artifacting) at these very low bitrates than Lame, at least with the
versions I had here, but I haven't done tests with all versions of either,
naturally. But I also read somewhere that Lame wasn't the best mp3 encoder
to use at these very low bitrates. If so, I presume that's due to the fact
that it was open-sourced and had fewer professional resources to develop it,
than the commercial Fraunhofer one (or the commercial WMA and AAC, for that
matter). But that's only my presumption.

"Bill in Co" wrote in
:

MP3 notes:
I also found that apparently the FhG mp3 encoder can work better (have
less artifacting) at these very low bitrates than Lame, at least with
the versions I had here, but I haven't done tests with all versions of
either, naturally. But I also read somewhere that Lame wasn't the best
mp3 encoder to use at these very low bitrates. If so, I presume that's
due to the fact that it was open-sourced and had fewer professional
resources to develop it, than the commercial Fraunhofer one (or the
commercial WMA and AAC, for that matter). But that's only my
presumption.



That could well be true. For a long time I held that the Fraunhofer encoder
beat LAME, and that if in doubt, it would be a better choice for anyone not
willing to agonise over presets. I think LAME does ok at higher bitrates
mainly because that was what people were interested in most at the time. They
wanted archivable quality with fairly small files, so the focus was on
anything at or above 128 kbps mostly, with the goal being 'transparency' (in
practise, inability to distinguish source from encode by ABX comparison) for
as many listeners as possible. This might be where the main focus is even
now, and might be why I could easily find improvements at low bitrates.

I also suspect that Fraunhofer's codec put more emphasis on basic methods
(noise shaping, and less complex masking) rather than more elaborate
psychoacoustics. They probably chose not to push too hard, which may be what
led to others later deciding to try just that.

"Bill in Co" wrote in
:

(And if we
encoded to mono, we could presumably cut the bitrate in half, since only
one channel would need to be processed, of course).


Something I didn't mention before... I think it is better to stay with stereo
channels at source but make them both equal. Then encode as joint stereo. The
result would be all mid-side (with no side being used, as the source channels
are equal), so the file size would be the same as mono, but the full stereo
output compatibility would be there. I remember that some players depended on
this.

(Note, never assume that a commercial stereo track based on original mono has
equal channels. I doscovered that they often don't! This is a case where good
amateur engineers can see how bad some professional work is.)

"Bill in Co" wrote in
m:

No, I gave up on OE for that (I did try it however and it was a futile
exercise, at least for me). So I used Xananews, which has worked ok
for me before. And I did it twice just to be sure.


Try Xnews?

What was fascinating about it was that after decoding and combining the
15 equal length segments, the result was a playable, 29 second file, but
with skipped over portions (or sections) of the actual content. I
would have expected otherwise (e.g: a bad, unplayable, file under such a
situation).


You didn't say how big it was (bytes) so I'm not sure what to make of it. If
same as I posted last night, last post, try the MD5 too. If size matches but
file size doesn't, you could try opening as a raw file. But that might only
work if any missing chunks had an even number of 16 bit words. And I bet the
result might not even be a lot different to what you got.

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

No, I gave up on OE for that (I did try it however and it was a futile
exercise, at least for me). So I used Xananews, which has worked ok
for me before. And I did it twice just to be sure.


Try Xnews?

What was fascinating about it was that after decoding and combining the
15 equal length segments, the result was a playable, 29 second file, but
with skipped over portions (or sections) of the actual content. I
would have expected otherwise (e.g: a bad, unplayable, file under such a
situation).


You didn't say how big it was (bytes) so I'm not sure what to make of it.
If
same as I posted last night, last post, try the MD5 too. If size matches
but
file size doesn't, you could try opening as a raw file. But that might
only
work if any missing chunks had an even number of 16 bit words. And I bet
the
result might not even be a lot different to what you got.

Not sure how to check the MD5. But what I did do is redownload it again
using XanaNews (wasn't crazy over the idea of installing another binary news
program since I so rarely use this).

Anyways, here is what happens:
You open up XanaNews; it shows 15 equal length parts of (supposedly)
9,289,832 bytes each, and they are in the correct order, ready to decode and
combine.

After it's all decoded and combined, the resultant file length for the WAV
file is 5,120,000 bytes. The wave player(s) say its 59 seconds long, but
you can only play 29 seconds before it stops, and those 29 seconds consist
of abbreviated segments of the show.

And, in fact, if I run this compromised wav file thru dbPowerAmp's Music
Converter just to reconvert it to another WAV file, the length does indeed
come out to be 29 seconds in the players, presumably because dbPowerAmp
Converter updates the WAV header info to be the correct value. (And
possibly is able to throw out some extraneous file stuff in the process as
it reconverts it, but that's only a possibility).

Lostgallifreyan wrote:
"Bill in Co" wrote in
:

MP3 notes:
I also found that apparently the FhG mp3 encoder can work better (have
less artifacting) at these very low bitrates than Lame, at least with
the versions I had here, but I haven't done tests with all versions of
either, naturally. But I also read somewhere that Lame wasn't the best
mp3 encoder to use at these very low bitrates. If so, I presume that's
due to the fact that it was open-sourced and had fewer professional
resources to develop it, than the commercial Fraunhofer one (or the
commercial WMA and AAC, for that matter). But that's only my
presumption.



That could well be true. For a long time I held that the Fraunhofer
encoder
beat LAME, and that if in doubt, it would be a better choice for anyone
not
willing to agonise over presets. I think LAME does ok at higher bitrates
mainly because that was what people were interested in most at the time.
They
wanted archivable quality with fairly small files, so the focus was on
anything at or above 128 kbps mostly, with the goal being 'transparency'
(in
practise, inability to distinguish source from encode by ABX comparison)
for
as many listeners as possible. This might be where the main focus is even
now, and might be why I could easily find improvements at low bitrates.

I also suspect that Fraunhofer's codec put more emphasis on basic methods
(noise shaping, and less complex masking) rather than more elaborate
psychoacoustics. They probably chose not to push too hard, which may be
what
led to others later deciding to try just that.

That may be.
Ironically, I've gotten the best results with the Fraunhofer MP3 encoder
that came with the old Abobe Audition 1.5, which allows for setting a LPF
filter cutoff, too (I set it to a bit under 9 kHz just to minimize some
artifacting, something we kinda indirectly mentioned already). But it was
significantly better than my Lame.

It's too bad Adobe really screwed it up with the later editions (meaning 2.0
and its successors). This 1.5 version is just like Cool Edit Pro, but it
added FSE, my best buddy, in so many of my restoration efforts. :-) But
alas, it wouldn't install on Win98SE. I think the last version that would
was possibly AA 1.0, and Cool Edit Pro, its predecessor (another good audio
editor), but both of them lack FSE. Oh, and the ability to see 4 audio
tracks, if useful; and the near instantaneous switching viewing capability
between the time domain and the frequency domain views of the audio.

Lostgallifreyan wrote:
"Bill in Co" wrote in
:

(And if we
encoded to mono, we could presumably cut the bitrate in half, since only
one channel would need to be processed, of course).


Something I didn't mention before... I think it is better to stay with
stereo
channels at source but make them both equal. Then encode as joint stereo.
The
result would be all mid-side (with no side being used, as the source
channels
are equal), so the file size would be the same as mono, but the full
stereo
output compatibility would be there. I remember that some players depended
on
this.

But I think if you save a file at say 128 kbps, using joint stereo, and with
identical channels, the total file size will still be twice what it would be
if you had used 64 kbps (using mono) in the first place. Or maybe that's
not in dispute.

But the broadcast recordings I used were in fact mono at the source, so that
wasn't applicable in my case. They only became stereoized when I added the
pseudostereo effect (comb filter + delays + reverb, basically).

And then when I made the file, I chose joint stereo, since it gives more
bits to the mid or sum channel, L+R, allowing for better use of the
composite bitrate (since the information in the difference or side channel,
L-R, is pretty limited).

(Note, never assume that a commercial stereo track based on original mono
has
equal channels. I doscovered that they often don't! This is a case where
good
amateur engineers can see how bad some professional work is.)

No, and related to this, I've sometimes cleaned up some (originally mono)
audio downloaded from the internet, like from some YouTube videos, but which
was saved in the file as 2 channel or stereo. I then remixed the almost
identical tracks to mono to get rid of some noiseor other artifacts.

The source was clearly mono in the first place, but whoever "recorded" it,
did it to 2 channels, and they weren't equal! As mentioned, I've found
this to be the case on some audio tracks extracted from some YouTube videos,
for example. (and then I can remux in the cleaned up audio later).

Bill in Co wrote:
and even then it's only useful for stuff like old radio broadcasts.

Not always. The problem is, MP3 eliminates things you can't hear, but
you definitely can hear the noise in old recordings. Encoding random
noise takes a huge bitrate, leaving little for the real content. I have
just digitized low quality mono family recordings for a friend and ended
up with the highest bitrate I have ever used for any material, below
that even I could hear artefacts, which says something.

I continue being surprised at radio streams. I've just replaced my
copies from brand new shop-bought BBC cassettes with recordings from a
44 kbps stream, because that had the better quality. I wouldn't dare
going below 80 kbps mono or 112 kbps stereo for plays myself. Readings
sound fine at 56 kbps, at least to my unsophisticated ear.

Axel