I have dozens of highly compressed videos of lectures, with audio tracks that were tightly compressed using Lame to 22kHz 32kbps vbr mono mp3. My problem is that my recently purchased Samsung tv is incompatible with mono; it plays these videos silently. To work around the tv's bug, I'd like to change the audio to a stereo format. But I don't want to lose more audio quality since the audio is already so tightly compressed, and I'd prefer not to increase the file size significantly if that can be avoided.
Joint stereo seems to make sense, in principle, because the Mid channel could simply be a copy of the mono (since copying is lossless and doesn't change size) and the Side channel would be all zero (which shouldn't require many bits). What I want is a tool that will construct the joint stereo that way. That seems simple and feasible in principle. It's not recompression; it's more like repackaging or muxing. But I don't know of any software that can do it, and I think it would take a lot of (scarce) time to develop the software myself.
Thanks in advance to anyone who can help!
In case lossless repackaging to joint stereo is either infeasible or not yet implemented... Should I consider recompressing to stereo aac, since aac supposedly outperforms mp3 at low bit rates? Would I need to increase the bitrate much above 32kbps to avoid losing significant quality? Given mono input, and assuming the encoder is set to output 2 channels, do aac encoders automatically produce joint stereo with a zero Side track?
P.S. -- Another lossless repackaging that might be feasible is mp3 to aac. I don't know enough about the differences between mp3 and aac to know whether this is truly feasible, but in many ways aac encoding techniques seem to be a superset of mp3 encoding techniques.
+ Reply to Thread
Results 1 to 15 of 15
@bat99: What bothers you about 32k vbr mono for human speech? It's compact and I have no trouble understanding the speech.
No. I think what bat999 is emoji-ing is that it is much more likely that your Samsung is baulking at a combination of VBR and 22kHz or 32kbps, rather than "mono".
Before you go down your road too far, do a test with a short LPCM (WAV) source: make copies of 22kHz vs. 44kHz, stereo/dualchannel vs. mono, and CBR vs. VBR. Maybe even 32kbps vs. 64/96/128kbps. All permutations would give you a total of 8 or 16 files, so it shouldn't take too long. Label them by their properties, and then see which ones play...
I say this, because VBR has been known in the past to cause problems for some hardware devices, and while most "mp3" players have no trouble with the Mpeg 1-layer 3 portion of the spec, they can/do have some trouble with the Mpeg 2-layer 3 portion (that portion that includes the low samplerate & low bitrate extensions, as well as the non-backward-compatible/aac-like, and multichannel extensions).
BTW, the idea of lossless reformatting mono->jointstereo could be a good idea...
@Cornucopia: I already ran a variety of tests with the Samsung tv. It was silent with mono files of much higher bitrates too. And it had no trouble playing stereo files at low bitrates. I didn't test as exhaustively as you suggest, but I think I ruled out 32k and vbr as possible culprits. Do you think a 32k vbr stereo file isn't an adequate comparison?
If that was what Bat999 meant, s/he should not have written so tersely.
Thanks for the reply, and for the comment that lossless mono-to-jointstereo could be a good idea.
32kbps vbr would be suspect to me in MUCH hardware, but what also concerns me is the 22kHz sampling. Mpeg1-L3 allows 32kHz, 44.1kHz and 48kHz sampling. Mpeg2-L3 allows those plus 11(.25?), 16 & 22(.5?)kHz (and maybe 8kHz, though my memory is fuzzy on that since I've never had a need for something so low quality). If the mp3 playback code in the Samsung is Mpeg1-compliant for audio, but not Mpeg2-compliant, that would account for the silence.
No one mentioned Audacity, but it should be able to convert the audio and you could listen to what the loss might be. You would need to add the Lame encoder for MP3 output.
Joint stereo would be easy enough and you may also add some filtering if the noise level seemed to increase after re-encoding.
lame uses "quality" not "bitrate" for vbr.
VBR options: -V n quality setting for VBR. default n=4 0=high quality,bigger files. 9=smaller files
Part way you might have been speeding along at 70mph but you might have been crawling in heavy traffic at only 10mph for the rest.
Perhaps use container to wrap mp3 - MPEG TS should be fine as mono files are common in TV Broadcast and IMHO Samsung should be able to decode them fine. - there will be some small overhead (2-5% maybe) for PSI/SI and packets but everything should be lossless.
@Cornucopia: I'll prepare some videos for a few more tests of the tv. I used mp4 containers for the lectures, so I'll test 22kHz vbr joint stereo mp3 at various low bitrates in mp4 too. According to my notes, the Lame encoding settings I used for the vbr mono were: MPEG II, minbitrate 8k, maxbitrate 64k, Quality Very High (q=0), and VBR Quality VBR7. For the new tests, I'll set jointstereo and use various maxbitrates.
@Bat999: I never claimed 32k was an encoder setting. It was the average bitrate of the mp3, as measured by G-Spot. Used in this sense, 32k VBR is not a contradiction; G-Spot in fact displays both 32k and VBR. When VLC plays files, it too displays bitrate, not encoder quality setting. So does Windows when I click on an mp3 file. So, listing a bitrate is valid and not a contradiction. I did indeed use Lame quality settings to approximately produce the desired average bitrate. Your car analogy is good, since it's VBR, not CBR. I presume G-Spot calculates average bitrate by dividing size by duration, which is like dividing 30 miles by 1 hour to get the car's average speed. Just as G-Spot can't determine the Lame quality settings, neither can the tv, so I think I was correct to list properties of the mp3 itself rather than encoder settings irrelevant to the tv. (By the way, 32k is just a representative value; my lecture videos' average audio bitrates range from about 30k to about 40k. All of them were silent, which meant the average bitrate wasn't a critical factor, so I simplified my question by listing just 32k, which was my desired rate. I'm sorry if this "simplification" confused anyone.)
@redwudz: Your suggestion to use Audacity with Lame to do a lossy re-encode does not answer my question about whether it's possible to losslessly repackage mono to joint stereo. However, if I do end up re-encoding, I'm considering using Apple's AAC encoder with the QAAC CLI front end, since Apple's AAC is well-regarded for quality at low bit rates, and maybe the tv will be more compatible with AAC than with MPEG II. I expect Audacity would be able to launch QAAC as an external encoder, which would allow use of Audacity's extensive editing features and filters.
@pandy: Thanks for the interesting idea about testing a different container. I used mp4 because I figured modern devices would be compatible, and the Samsung tv's specs claim compatibility with mp3 contained in mp4. I'll test by using Avidemux to remux to MPEG TS. And I may as well test the MP4v2 container's option to optimize for streaming.
I did more testing of the Samsung tv, using joint stereo in mp4, and using mono in ts and mp4v2(with moov at the front for streaming). Cornucopia appears to be correct that the problem is the 22 kHz sampling rate, not the mono. Pandy is right that the tv is able to handle the 22 kHz when contained in ts. Unfortunately, the tv couldn't handle the video properly in ts; the video alternately froze and then fast forwarded (while the audio sounded fine). Even if the video had played well, though, I'd be reluctant to get rid of my mp4 files in exchange for ts files since I don't know how compatible ts is with other devices.
Anyway, I may start another forum thread to ask whether it's possible in principle to upsample from 22 kHz to a sampling rate compatible with the tv, with no loss of quality. (Perhaps 44 kHz, and either duplication or interpolation to create the extra samples?) Alternatively, is it worth starting a thread to ask whether it's possible in principle to losslessly "repackage" 22 kHz mp3 as 22 kHz aac, to attain compatibility with devices that handle aac better than mp3 II yet avoid significant increase in size?
Thanks for all your help!
Well, don't be confused with quality loss - it should be marginal (from perceptual perspective) side to this you may even improve perceived quality, video can be converted to something more broadcast standard (H.264). Resampling should be not a problem.
@Pandy: When you wrote quality loss should be marginal, were you referring to transcoding to 22 kHz aac or to 44 kHz mp3? If you mean aac, are you assuming I use Apple's encoder?
The video is already x264. (That's what alternated between pausing and fast-forwarding when I repackaged into a .ts container.)
Fitting bitrate is something else - problem is that in 44kHz mp3 bitrate cant drop bellow 32kbps (minimum bitrate allowed by mp3) as such or you will go for something that can be more flexible and at the same time more efficient at low bitrates than mp3 or increase file size is unavoidable. But you mentioned video - i think you may gain way better compression and as such video bitrate reduction ma create file size lower than before even if mp3 bitrate will be higher.
Of course everything is pure speculation as without sample we talking on highly hypothetical scenario.
@Pandy: I'm unsure whether your suggestion of a codec "more flexible and more efficient at low bitrates than mp3" means aac. I could do a quick test using the two aac encoders built into Avidemux, but tests using Apple's aac or Fraunhofer's aac would require more setup and learning since I've never used them.
Regarding reducing the video bitrate to reduce filesize, they're already compressed fairly tight, encoded at 250 or 300 kbps (average bitrate) for 632x480. I tested with significantly smaller bitrates but the resultant video looked annoying. Slightly smaller bitrates might look okay.
It should be noted that the video is almost 30 frames per second. I could reduce the frame rate, perhaps to 15 fps, to facilitate significantly smaller bitrate without reducing bits per frame. My understanding is that re-encoding would be required, since deleting frames in principle could not work since decodability of frames (except I-frames) depends on neighboring frames.
Assuming I reduce the video frame rate and video bitrate, I would still prefer not to increase audio size more than necessary. This is why I have continued to ask about reencoding to aac, instead of 32kbps cbr mp3 or >32kbps vbr mp3. Can anyone advise regarding the suitability of Apple's or Fraunhofer's aac for my purpose? Are any codecs better for speech than aac, without sacrificing compatibility with players?
I interpreted "without sample we're speculating" as a hint/invitation to upload. So I've attached an 8 second excerpt of one of the mp4 lectures. I've also attached a little .png image that shows the Samsung tv's alleged video and audio codec compatibilities.