file specs are ok (checker, ubuntu, windows) but it has 129 kbps

Post your questions & get help from friendly LibriVoxers
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

hi all,

i use: audacity 2.2.1 on ubuntu linux, checker 0,96 with openjdk java 8

audacity settings for exporting:
Image

my bc project ruebezahl cannot get catalogued, because there is a failure message: all of my files seem to have 129 kbps.
it's only my files, which have this syndrom.
now, availle told me, that the files seem to be ok - also according to her windows system.

and i think i could try to use ffmpeg commandline, ardour, a converter programme or whatever - but i even cannot see, what the specs are (according to the librivox software).

so, anyone any experiences, hints or advice or tricks?

edit: my checker info
Image
cheers
wolfi
reader/12275
annise
LibriVox Admin Team
Posts: 38653
Joined: April 3rd, 2008, 3:55 am
Location: Melbourne,Australia

Post by annise »

On my experience the 129 have become 128 when I exported failed files with constant bit rate and uploaded , I've never investigated any further.
Checker is designed as an aid for PLing , it was never meant to be an absolute bench mark

Anne
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

annise wrote: July 15th, 2018, 4:39 am On my experience the 129 have become 128 when I exported failed files with constant bit rate and uploaded , I've never investigated any further.
Checker is designed as an aid for PLing , it was never meant to be an absolute bench mark

Anne
we tried to save the file again and upload it, already.
my audacity export-settings are as shown above.

and the checker image shows my 3 files: one bunch of them the "original" files, the second bunch showing a downloaded version, saved into a separate file, re-saved with settings according to the image (and re-uploaded: failed again).

so, i didnt mean to claim checker as the benchmark - but i see my files as ok, only. they are constant bitrate, 128 kbps according to ubuntu, windows, checker and audacity settings.

and now i dont know what to do about this somewhat mysterious mistake, which may be a linux problem, an audacity problem, a codec problem, or i dont know what....
cheers
wolfi
reader/12275
GrayHouse
Posts: 639
Joined: October 6th, 2012, 3:27 pm

Post by GrayHouse »

I've looked at your file: ruebezahlbuch_05_hauptmann_128kb.mp3 using some other programs, and it looks fine.

I'm not an LV Admin, so I'm not familiar with the cataloguing process, but I presume some piece of software at Archive.org is checking and rejecting the file???

I suspect there's nothing wrong with the way your files are encoded - you're using a 'standard' process and you have sections in other catalogued projects which worked fine.

I've seen something like this before (not on LV) where different mp3 headers and tags caused the files to be treated differently. The process of working out a file's bitrate is surprisingly complicated!

Readers' files have mp3 tags added automatically before being cataloged. I wonder if that's causing problems. Presumably project admins have access to the tagged files. It might help if the project BC/MC could upload one of the tagged files so we can have a look at it.
-Ian
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

GrayHouse wrote: July 15th, 2018, 5:35 am I've looked at your file: ruebezahlbuch_05_hauptmann_128kb.mp3 using some other programs, and it looks fine.

I'm not an LV Admin, so I'm not familiar with the cataloguing process, but I presume some piece of software at Archive.org is checking and rejecting the file???

I suspect there's nothing wrong with the way your files are encoded - you're using a 'standard' process and you have sections in other catalogued projects which worked fine.

I've seen something like this before (not on LV) where different mp3 headers and tags caused the files to be treated differently. The process of working out a file's bitrate is surprisingly complicated!

Readers' files have mp3 tags added automatically before being cataloged. I wonder if that's causing problems. Presumably project admins have access to the tagged files. It might help if the project BC/MC could upload one of the tagged files so we can have a look at it.
-Ian
Availle wrote: July 15th, 2018, 3:56 am Den Fehler sehe ich hier bevor ich etwas nach archive hochlade.
Wenn ich den Fehler erst auf archive bemerke, ist es zu spaet:

die ganzen fileformate wie .ogg, 64kbps, .zip usw. werden von archive selbst aus unseren 128kb files hergestellt. Das funktioniert aber nur wenn es echte 128kb constant files sind. Deshalb sind wir hier so pingelig wegen der Bitrate. :wink:
edit: thank you GrayHouse! :D


hallo availle,

könnte es an den tags liegen?
sind die ergebnis-dateien andere dateien alsdie hochgeladenen und von uns verlinkten, auf die wir zugang haben?

and in english: could the tags be the problem? are that resulting files the same files as uploaded and linked, or are they "new" files we dont have access to?

cheers
cheers
wolfi
reader/12275
Availle
LibriVox Admin Team
Posts: 22445
Joined: August 1st, 2009, 11:30 pm
Contact:

Post by Availle »

As far as I can see from your file that I downloaded, you didn't set any ID3 Tags yourself. :hmm:

During cataloging, the appropriate tags are populated from what's in the MW (section titles) or in the database (author name and book title). That's the same for everybody's files, so I doubt that this is the problem.
Cheers, Ava.
Resident witch of LibriVox, channelling
Granny Weatherwax: "I ain't Nice."

--
AvailleAudio.com
DaleInTexas
Posts: 164
Joined: August 15th, 2012, 12:43 pm
Location: West of Cowtown, Texas
Contact:

Post by DaleInTexas »

Schrm,
Reading your post got me to thinking that the problem may lie in how the file is being encoded to MP3, in the Linux environment. This prompted some research for me, since I have never used Linux. My Quick hypothesis: I think LAME 3.100 may be the problem in how it encodes signal above 16kHZ and/or speed, ruling out Linux.

I read the change log for LAME v3.99.5 where it fixed a bug that caused "bit rate bloat." My further research about this issue tells of a problem where the encoding to MP3, and its inefficiency of encoding audio signal >16kHZ to MP3, causes a bloat in the (VBR) bitrate encoding that uses fast floating point math. Not confirmed: but I was led to believe, from one of the posts, that LAME has an "extreme"-setting and a "standard (slower)"-setting, to adjust the math calculation speed that is used for encoding. Easiest suggestion to try: looking at your screenshot of your Audacity Export-settings, change from [Variable Speed] FAST, to a lower (slower) encoding setting.

So my pondering moved me to question: hmmmm, I wonder if he is experiencing the same >16kHz issue, even though he is using LAME 3.100? All checkers report a 128kbps CBR, but he has reports of 129 from Archive... Hmmm Why?

If you are so inclined to experiment, I would suggest applying a LPF to all frequencies above 16kHz. You can go back to your last saved iteration of your raw and mastered file, and apply an EQ-cut to everything above 15kHz, then bounce a new, Final MP3. Since those freqs are above Human hearing range (maybe some teenagers) and not useful data to be recorded anyhow. Adult hearing begins dropping off about 15kHz. Anything above that is not really useful. I make it a standard practice to kill all signal below 80Hz, and all above 15kHz, since that just eats up signal energy that I will boost later, in my mastering process, to get up to LV loudness levels.

OK- enough of my (maybe useless) cogitation,
Dale
Dale Latham
Down on the Poor Farm
https://twitter.com/dalelatham
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

DaleInTexas wrote: July 15th, 2018, 8:21 am Schrm,
Reading your post got me to thinking that the problem may lie in how the file is being encoded to MP3, in the Linux environment. This prompted some research for me, since I have never used Linux. My Quick hypothesis: I think LAME 3.100 may be the problem in how it encodes signal above 16kHZ and/or speed, ruling out Linux.

I read the change log for LAME v3.99.5 where it fixed a bug that caused "bit rate bloat." My further research about this issue tells of a problem where the encoding to MP3, and its inefficiency of encoding audio signal >16kHZ to MP3, causes a bloat in the (VBR) bitrate encoding that uses fast floating point math. Not confirmed: but I was led to believe, from one of the posts, that LAME has an "extreme"-setting and a "standard (slower)"-setting, to adjust the math calculation speed that is used for encoding. Easiest suggestion to try: looking at your screenshot of your Audacity Export-settings, change from [Variable Speed] FAST, to a lower (slower) encoding setting.

So my pondering moved me to question: hmmmm, I wonder if he is experiencing the same >16kHz issue, even though he is using LAME 3.100? All checkers report a 128kbps CBR, but he has reports of 129 from Archive... Hmmm Why?

If you are so inclined to experiment, I would suggest applying a LPF to all frequencies above 16kHz. You can go back to your last saved iteration of your raw and mastered file, and apply an EQ-cut to everything above 15kHz, then bounce a new, Final MP3. Since those freqs are above Human hearing range (maybe some teenagers) and not useful data to be recorded anyhow. Adult hearing begins dropping off about 15kHz. Anything above that is not really useful. I make it a standard practice to kill all signal below 80Hz, and all above 15kHz, since that just eats up signal energy that I will boost later, in my mastering process, to get up to LV loudness levels.

OK- enough of my (maybe useless) cogitation,
Dale
hi dale,

and first: thank you for your research and post!
not uselessat all, but way above my knowledge to be honest..
im a linux desktop user with some experience in commandline, no linux nor programming nor audio/tech/physics skills..

i will try to look into that area and try to change the encoding, first.
what i remember, there are several different codecs for creating mp3..

you gave me some hints, where to look for: thank you again!

cheers,


edit: the bloating happens in filesize, seems to be, not in the bitrate.
but maybe its best, to try and upload some differently produced testfiles...
still having the problem, that the files seem to be ok on whichever method of checking them i try
cheers
wolfi
reader/12275
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

well i tried mp3diags, a tool to amalyse and repair mp3 files.

cbr 128.000 is found, but there are other messsages (also, for all of my pled files there are several messages.)

since this problem affects my files, maybe it has to do with them?
can anyone help me in understanding the output:

Image
Image
(please ignore the cursor-arrow, its just random)

and @dale:
can you give me this "audio signal >16kHZ" thing is something i can do with audacity?

@availle ich kann ein paar testdateien hochladen zb bei tests, und du schaust, ob eines davon akzeptiert wird?
cheers
wolfi
reader/12275
GrayHouse
Posts: 639
Joined: October 6th, 2012, 3:27 pm

Post by GrayHouse »

schrm,
As I understand that program, the All Notes button shows you the errors for all files in the folder you selected. So it depends on what else is in that folder.

Select each of your project files in turn (in the top grid) and check the errors that appear in the grid below with the File Info button pressed.

The 'errors' fa, ob and an are all perfectly normal, so they're not a problem. If you have only those 'errors' then everything is OK (according to that program).

-Ian
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

GrayHouse wrote: July 15th, 2018, 11:40 am schrm,
As I understand that program, the All Notes button shows you the errors for all files in the folder you selected. So it depends on what else is in that folder.

Select each of your project files in turn (in the top grid) and check the errors that appear in the grid below with the File Info button pressed.

The 'errors' fa, ob and an are all perfectly normal, so they're not a problem. If you have only those 'errors' then everything is OK (according to that program).

-Ian
thank you!
seems plausible to me!

so my files are ok according to just another software and still...
cheers
wolfi
reader/12275
DaleInTexas
Posts: 164
Joined: August 15th, 2012, 12:43 pm
Location: West of Cowtown, Texas
Contact:

Post by DaleInTexas »

schrm wrote: July 15th, 2018, 9:19 am i will try to look into that area and try to change the encoding, first.
what i remember, there are several different codecs for creating mp3.. {No need to change the codecs. Go back to your last saved iteration of your raw and mastered file, change Audacity's "Variable Speed" setting, from the dropdown, to a lower setting, and re-render to a new MP3.}

cheers,

edit: the bloating happens in filesize, seems to be, not in the bitrate. {Maybe I misunderstood your original post.. I thought you stated that Archive was rejecting them because they reported as 129kbps?}


@dale:
can you give me this "audio signal >16kHZ" thing is something i can do with audacity?
Schrm,
What I do is apply an EQ-effect, early in my editing process (before any compression or adding gain), with the settings for a High Pass Filter (HPF) and Low Pass Filter (LPF). On the EQ, I pull every frequency-band slider, from 80Hz and below, down to Zero. This cuts those frequencies out of my audio recording and allows all of the other Higher frequencies to Pass though the Filter. On the same instance of the EQ, I also pull all of the frequency bands, from 15kHz and above, to Zero. This cuts those frequencies and allows all of the signal's Lower frequencies to Pass through the Filter. {the nomenclature sounds odd that an HPF is applied to low freqs and LPF is applied to high freqs}

Although I use the DAW called Reaper for my VO work, I also use Audacity occasionally for some preset work. In Reaper, I have manually created an EQ preset, per my own HPF/LPF taste. You can do the same in the Multi-band EQ effect, in Audacity. Audacity also has HPF and LPF effects, in the Effects Menu. Personally, I do not like to use HPF and LPF plug-ins because they have a tendancy to start their cuts a little higher or lower in frequency, than my 80Hz and 15kHz preference.
Dale

EDIT: I just checked the Audacity HPF and LPF effects and they are programmable. You can set the cutoff frequency and gain reduction to a max -48dB.
Last edited by DaleInTexas on July 15th, 2018, 1:19 pm, edited 2 times in total.
Dale Latham
Down on the Poor Farm
https://twitter.com/dalelatham
knotyouraveragejo
LibriVox Admin Team
Posts: 22120
Joined: November 18th, 2006, 4:37 pm

Post by knotyouraveragejo »

schrm - the only difference that I can see in Checker is that you are using a different version of LAME than most LV Audacity users (3.100 vs 3.99r). The problem is that our validation software is reporting your files as 129 instead of 128, even though they are encoded at 128kbps. When I have seen this before, I usually assume it's a variable rate and download, open and reexport the file which fixes it. I don't know if this is related to the version of LAME or something else, but all we can do at present is add it to the bug list for a future update of the LV cataloging software.
Jo
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

thank you all for your input!

@dale will try! Thx for guidance!

@knotyouraveragejo thx For your help and Explanation!
that is why the problems, but... in short that means for me:
I am not able to deliver ok files...

Notes:
I will look into lame versions, maybe there is a newer Version or another numbering System for Linux. Lame is decent Standard what i read, tough. And i already used gstreamer based MP3diags, another Implementation i think.
And dale hinted to a workaround i will try
(Every trial and error File has to be uploaded and validated - doesnt sound good)
...another day..
cheers
wolfi
reader/12275
schrm
Posts: 4211
Joined: February 10th, 2018, 11:02 am
Location: Austria

Post by schrm »

thank you all for your input!

@dale will try! Thx for guidance!

@knotyouraveragejo thx For your help and Explanation!
that is why the problems, but... in short that means for me:
I am not able to deliver ok files...

Notes:
I will look into lame versions, maybe there is a newer Version or another numbering System for Linux. Lame is decent Standard what i read, tough. And i already used gstreamer based MP3diags, another Implementation i think.
And dale hinted to a workaround i will try
(Every trial and error File has to be uploaded and validated - doesnt sound good)
...another day..
cheers
wolfi
reader/12275
Post Reply