Win7-32, SP1 and Audacity 2.1.1
I do a lot of capture from audio streams (typically a lecture or discussion) and many times EXPORT the results as 22k or 16k FLAC files, later to export MP3 after editing complete. If I try to export as an 11k FLAC file, the audio is small filesize wise, but it’s cut in half. That means the second half is missing.
Why does this happen? does one need to start with a 44k source file? Didn’t do enough of these to notice trend.
TIA,
ED
What do you mean?
FLAC does not do VBR.
What do you mean by 16k and 22k?
EXPORT the results as 22k or 16k VBR FLAC files, later to export MP3 after editing complete. If I try to export as an 11k FLAC file, the audio is small filesize wise, but it’s cut in half. That means the second half is missing.
Are you sure the 2nd half is missing?
If you take a FLAC with a sample rate of 22kHz and downsample it to 11kHz, there’s half as many samples and it will be (approximately) half the size.
The same thing will happen with a WAV file… If you cut the sample rate in half, you have half as many samples so the file is half the size.
This won’t happen with lossy formats like MP3 unless you also cut the bitrate (kbps) in half.
FYI - The sample rate (kHz) limits the high audio frequencies in your file. You can only store audio up to half the sample rate. For example, audio CDs at 44.1kHz are limited to audio of 22,050Hz. At a sample rate of 11kHz, audio can’t go any higher than 5.5khz, which is about the frequency range of AM radio or telephone.
The “traditional” audio range is 20Hz to 20,000Hz. …Young people with good hearing can hear to about 20kHz.
Yes thank you, I’m well aware of that, Lol and trying for an audio bandwidth of 11 kHz, 8kHz and 5.5 kHz (like the old phone lines) respectively.
Maybe the problem is lowering the bitrate as you describe?
The exported audio… has the second half missing.
-Ed
Weird… I have no idea why the 2nd half is missing… How long are your files (playing time)?
There is a file size limit for WAV (2gB or 4GB depending on which spec you read) but there’s no similar limit for FLAC and MP3.
I’ve made some FLACS and MP3s that were more than 4 hours, and I’ve never had that problem…
If I try to export as an 11k FLAC file, the audio is small filesize wise, but it’s cut in half. That means the second half is missing.
Have you tried exporting directly to MP3, or to WAV?
We should also be clear that “11 kHz” and “22 kHz” are non-standard. It’s 11025 Hz (11.025 kHz) and 22050 Hz (22.050 kHz).
You can’t directly control the FLAC bitrate - that’s determined by sample rate, bit depth and number of channels.
Gale
Thanks for that.
Admittedly I was confused about what file-type the issue was affecting. It was probably happening with MP3.
Have been saving ALL audios as FLAC lately after installing a new 2T hard drive, mostly because you can edit and ‘resave’ FLAC with little or no reduction in quality. MP3 is the final export IMHO, like a JPG image.
In my defense, and leading to the confusion, Winamp 2.64 displays kbps and kHz which I see jumping around while a FLAC is playing.
Here’s a 2-frame animation of a FLAC saved at Q=9 (lowest for a voice lecture) with bitrate varying, and the title in a marquee display.
-Ed
p.s. I’m very seriously thinking of donating to encourage further development of this app…
Yes… Here is the spectrum of the file displayed in the animation above. Again this App is GREAT.
Log scale
Linear scale
The audio was a Youtube soundtrack rip, and now I see it was probably an 11 kHz (5.5 kHz bandwidth) originally?
Does FLAC generate energy in the 5.5 - 11 kHz range when coding?
What is your explanation of this… anyone?
Only the bit rate is “changing”.
Winamp aren’t exactly wrong. FLAC does compress much more when there is silence than when there is white noise, which has full bandwidth. For example, 30 seconds of silence encoded as 16-bit mono 22050 Hz FLAC makes a file of about 200 kB size, while 30 seconds of noise at 0.8 amplitude encoded as 16-bit mono 22050 Hz FLAC makes a file of about 1.2 MB size.
In comparison, 30 seconds of silence or 30 seconds of white noise encoded as 16-bit mono 22050 Hz WAV both make a file of about 1.2 MB. So you can see that the FLAC noise file saves no file size at all compared to WAV, but the FLAC silence file saves a vast amount compared to WAV. For “normal” audio content FLAC would turn out at about half the file size that a WAV would have.
Probably the lower bit rate Winamp shows is where the speaker was between words.
The point remains that you cannot set a bit rate when encoding FLAC. The resulting bit rate comes from the length, bit depth and sample rate (as with WAV) but reduced if the content is easy to predict and encode. The FLAC FAQ explains it thus:
https://xiph.org/flac/faq.html#general__lowest_bitrate.
Please do, if you can: http://audacityteam.org/donate/.
Gale
Re-encoding at a higher sample rate never adds frequencies that were not there in the first place - it only provides the possibility that higher frequencies could be added.
Most likely the audio was filtered to reduce “honkiness” that too much midrange can cause.
Gale
Ok thanks.
So we don’t get too far OT, and since I’m working with ALL lossless FLAC now (except to upload or attach clips to email), will pick this thread up again when the issue happens next… that is losing the 2nd half of the audio when exporting (re-sampling) at 11 kHz.
-Ed
The issue happened aGaiN last night while exporting a 22 kHz FLAC to an 11 kHz MP3.
Exporting to 16 kHz MP3 yields the desired results, but when exporting to 11 kHz, Winamp was displaying all playtimes as 1/2 of actual. It displays entire file as 1/2 the number of min:sec, and I believe any other time mid-file as 1/2 the actual time. (hope that is clear)
Investigation
Here are FOUR files displayed in Audacity with a `fit vertically´ layout.
The FLAC file on top is on top, then 22k MP3 export, the 16k MP3, and 11k MP3 at bottom.
Notice minor clipping in MP3’s
So I’d say there’s a bug in either Winamp, or the file metadata? the header?
What could cause the ‘client’ to display the time wrong? if file data is correct?
-Ed
Once again, those rates are non-standard. For maximum compatibility export as 11025 Hz by selecting that rate, not by typing in 11000 Hz (if you are doing that). By contrast, 16000 Hz is a standard rate.
Do you mean those are the files that you exported, then re-imported into Audacity? If so the bug does not seem to be in Audacity.
MP3’s are lossy. They adjust encoded volume slightly according to what is thrown away and what retained. If you use the highest MP3 export bitrate (320 kbps CBR) the volume adjustment is less likely to happen. Audacity would have to intervene somehow to restore the original peak level if this was to be avoided.
Gale
Thanks man, we can discontinue focusing on “non-standard rates.” I’m using standard rates from the menu, or pull-down menu. You mean a custom sample rate can be entered? That sounds odd. What would it be used for?
Yes, those are the files exported from Audacity, then ‘dropped’ (drag and drop from file manager/explorer) onto a New Audacity window. I’d say there’s a bug in Winamp, and am sure Audacity is strictly coded, seeing how precise it is. The problem with Winamp didn’t appear until using Audacity in the last year. Been running it for 10-15 years prior and never had an issue.
Slight clipping in MP3’s is a non-issue. I’m aware of encoding errors, and those clips are so minor… in the range of 0.00 to 0.1 dB
What criteria does Audacity used to determine a RED clip indication? (this is going OT)
-Ed
Because Integer formats (16-bit and 24-bit) have an absolute ceiling of 0 dB, if Audacity looked for “over 0 dB”, then it would never show clipping for integer format tracks. So what Audacity does is to show the warning indicators “at” 0 dB. Note that this means that the audio may not actually be clipped, but if sample values are at 0 dB, then the audio is dangerously high and “probably” clipped. Consider the red “clip indicators” to be a “warning” rather than anything else.
There will always be someone who needs some “non-standard” rate for some purpose. The only point I am making is that such non-standard rates, if used, could cause problems in some players. In my opinion, Winamp is being sloppy by displaying “11 kHz” when it is not.
Well, I imported a 22050 Hz FLAC (3 minutes 38 seconds) into Audacity, exported as 11025 Hz MP3 (64 kbps), opened it in Winamp 2.64 and it played the correct length in Winamp.
Winamp is discontinued but if you want to pursue it further I suggest you post the actual offending MP3 file somewhere.
Gale