IPB

Welcome Guest ( Log In | Register )

24 Pages V  « < 2 3 4 5 6 > »   
Reply to this topicStart new topic
MP3 repacker
Merlin744
post Jan 20 2006, 23:49
Post #76





Group: Members
Posts: 12
Joined: 11-January 06
Member No.: 27037



I was so sad when I first read that pioneer forum last week.

now, I am sooooooo glad this thing works!! biggrin.gif

if it could deal with sub-folders inside of the main folder... that would be even better. but now I'm just being picky laugh.gif
Go to the top of the page
+Quote Post
psyllium
post Jan 21 2006, 11:13
Post #77





Group: Members
Posts: 75
Joined: 29-December 05
Member No.: 26730



QUOTE (Merlin744 @ Jan 21 2006, 08:49 AM)
I was so sad when I first read that pioneer forum last week. 

now, I am sooooooo glad this thing works!! biggrin.gif

if it could deal with sub-folders inside of the main folder... that would be even better.  but now I'm just being picky laugh.gif
*


My GUI front-end for this script is available here: http://www.hydrogenaudio.org/forums/index....showtopic=40780
Features batch processing and folder recursion
Go to the top of the page
+Quote Post
Omion
post Jan 25 2006, 08:59
Post #78





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



Just released 0.08. If you don't use the -b switch, you don't care tongue.gif

Basically there was a discrepancy with handling of CBR files. psyllium noted that inputting a 128kbps file with the "-b 128" switch resulted in a VBR file, not the CBR one would expect. The vast majority of the frames were 128kbps, but ~1% were 160.

As a fix, 0.08 now assumes padded frames for valid bitrates, and unpadded frames for invalid ones. For example:
"-b 129" -> UNpadded 160
"-b 128" -> PADDED 128
"-b 127" -> UNpadded 128
"-b 126" -> UNpadded 128
"-b 113" -> UNpadded 128
"-b 112" -> PADDED 112
"-b 111" -> UNpadded 112
etc.

The problem was that the -b switch (before 0.08) assumed unpadded frames, so using "-b 128" REALLY meant "-b 127.706", which opened the door for a 160kbps frame to sneak through (remember that lowering the minimum bitrate tends to raise the maximum bitrate). Now using "-b 128" assumes padded frames, so turns into "-b 128.013". This is enough to guarantee a CBR128 file stays a CBR128 file, but at the expense of a little more wasted space (On the order of 1 bit per frame)


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
robert
post Jan 25 2006, 23:30
Post #79


LAME developer


Group: Developer
Posts: 783
Joined: 22-September 01
Member No.: 5



padding is only needed for CBR at 44.1, 22.05 or 11.025 kHz. it should be done such that the actual bitrate is always less or equal to the desired bitrate. you may look into the LAME sources or read about it in MPEG-Layer3 Bitstream Syntax and Decoding. You can find that document at Gabriel's "mp3-tech" site: http://www.mp3-tech.org/programmer/docs/96-05.pdf
Go to the top of the page
+Quote Post
psyllium
post Jan 26 2006, 03:04
Post #80





Group: Members
Posts: 75
Joined: 29-December 05
Member No.: 26730



A new version, 0.3 beta, of WinMP3Packer has been released which caters for version 0.08 of mp3packer.pl.

Check the thread here
Go to the top of the page
+Quote Post
Omion
post Jan 27 2006, 05:43
Post #81





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



Released 0.09.

Better support for whole directories. Specifically, the -f switch now works on directories, and the -X switch works with single files. Plus, added support for an output directory.

The other addition is the -i switch, which should be of interest to psyllium. It outputs a whole bunch of info, then exits. An example of the output:
CODE
INFO:
 MPEG1 layer 3
 13963 frames
 44100 Hz
 38.28125 frames per second
 364.747755102041 seconds
 6582738 bytes in file (144.37896673351 kbps)
 6582123 bytes in MP3 frames (144.365477959608 kbps)
 6078362 bytes of payload data (133.316505228103 kbps)
 6581030 bytes of MP3 data (144.341505228103 kbps)
 1093 bytes of padding (0.023972731504691 kbps)
 615 bytes outside MP3 frames (0.0134887739024565 kbps)
 Bitrate distribution:
  032: 27,0
  040: 8,0
  048: 7,0
  056: 14,0
  064: 28,0
  080: 187,0
  096: 812,0
  112: 1976,0
  128: 3834,0
  160: 4810,0
  192: 2082,0
  224: 163,0
  256: 15,0
 Smallest bitrate for CBR is 192

The filst few lines should be self-explanatory. All the bitrates are calculated slightly differently:
1st bitrate: bytes in file / second. Includes the tags and non-frame data
2nd: This is the "normal" bitrate, consisting of all the frame data
3rd: The amount of MP3 payload data, without the header, side info, or padding
4th: Payload data + header + side info. This is the theoretical minimum bitrate that mp3packer can pack to.
5th and 6th: How much is used up by padding and non-MP3 data, respectively

Then comes the bitrate distribution: The number of unpadded, padded frames at each bitrate (The example file didn't use padded frames)

Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
psyllium
post Feb 2 2006, 16:25
Post #82





Group: Members
Posts: 75
Joined: 29-December 05
Member No.: 26730



QUOTE (Omion @ Jan 27 2006, 03:43 PM)
Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.
*


Sweet as dude smile.gif I'll add support for that when my brain returns from holidays... in a few days I reckon...
Go to the top of the page
+Quote Post
jaybeee
post Feb 8 2006, 22:01
Post #83





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



Getting this error:
CODE
ERROR: Can't run frame location on layer 1 or 2 data at mp3.pm line 1094.


I've tried via both the GUI & commanline and same. Ran a basic command of: 'mp3packer.pl -a -vbr'

Interestingly, the GUI shows this file as being 128kbps, whereas MRQ shows 320kbps FhG.

Any ideas?

This post has been edited by jaybeee: Feb 8 2006, 22:01


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
Omion
post Feb 9 2006, 07:35
Post #84





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



That sounds like what Firon's problem on post 55 was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else wink.gif


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
kevinsham
post Feb 12 2006, 08:10
Post #85





Group: Members
Posts: 47
Joined: 23-April 02
Member No.: 1856



I am constantly getting this error message:

Wide character in print at C:\mp3packer/mp3.pm line 866.

The output file does not show correct length in foobar.
Go to the top of the page
+Quote Post
Omion
post Feb 12 2006, 08:33
Post #86





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



Hmmm... that's where the program writes the LAME header. I have a lot of chr(....) statements which could result in a Unicode character slipping by once in a while, although obviously it shouldn't.

What kind of files make this error? Are they massively long? What command line are you using (or are you using psylium's GUI)? Does the file play OK? What if you use Foobar's "fix mp3 header"? (I think that's enough questions for now wink.gif )

This post has been edited by Omion: Feb 12 2006, 08:37


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
UED77
post Feb 12 2006, 09:10
Post #87





Group: Members
Posts: 41
Joined: 12-February 06
Member No.: 27709



Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line wink.gif

The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:
  • The copy was 3456 samples "behind" the original file, meaning that every single sample was shifted 3 frames.
  • The copy omits last 2304 samples of the original file altogether, even if not using -s. (This also happened with the b-a test above).
  • Approximately the first two frames of the copy contain modifications to the actual waveform, distorting the audio data in those first ~50 ms.

I do not know what might cause these problems, as I have removed tags from my input files... So that's why I'm turning to you for help.

Thanks,

UED77


--------------------
UED77
wavpack 4.50 -hx3; lame 3.97 -V4 --vbr-new
Go to the top of the page
+Quote Post
Omion
post Feb 12 2006, 09:51
Post #88





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



QUOTE (UED77 @ Feb 12 2006, 01:10 AM)
Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line wink.gif


Does Audacity dither the audio? That would be the most obvious explanation. My program doesn't decode any of the data, so if it messed it up it would probably be a LOT more noticabe than "generally inaudible". It's just about impossible for mp3packer to change the data a little bit. It'll either be perfect, offset by a multiple of 1152, or complete garbage. Try Foobar's "bit-compare files" feature; I know it works (and doesn't dither).

QUOTE
The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:
  • The copy was 3456 samples "behind" the original file, meaning that every single sample was shifted 3 frames.
  • The copy omits last 2304 samples of the original file altogether, even if not using -s. (This also happened with the b-a test above).
  • Approximately the first two frames of the copy contain modifications to the actual waveform, distorting the audio data in those first ~50 ms.
*

That's a bit bizarre. Even if the program is misinterpreting the XING tag, it should still only be off by 1152 samples. It sounds like something in the file is confusing my proggie. What version of Perl do you have?

This post has been edited by Omion: Feb 12 2006, 10:00


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
kevinsham
post Feb 12 2006, 10:11
Post #89





Group: Members
Posts: 47
Joined: 23-April 02
Member No.: 1856



It seems that mp3packer is chopping the file. See the following output for running mp3packer for multiple times.

C:\>mp3packer 5.mp3 5a.mp3
Pre-parsing frame 3836
On frame 3836 of 3836
Output file uses frame sizes from 32 to 320
3836 frames in 1520131 bytes

C:\>mp3packer 5a.mp3 5b.mp3
Pre-parsing frame 3825
On frame 3825 of 3825
Output file uses frame sizes from 32 to 320
3825 frames in 1519171 bytes

C:\>mp3packer 5b.mp3 5c.mp3
Pre-parsing frame 3815
On frame 3815 of 3815
Output file uses frame sizes from 32 to 320
3815 frames in 1518211 bytes

C:\>mp3packer 5c.mp3 5d.mp3
Pre-parsing frame 3805
On frame 3805 of 3805
Output file uses frame sizes from 32 to 320
3805 frames in 1517251 bytes
Go to the top of the page
+Quote Post
Omion
post Feb 12 2006, 10:34
Post #90





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



QUOTE (kevinsham @ Feb 12 2006, 02:11 AM)
It seems that mp3packer is chopping the file.
*

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:
CODE
#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)


I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.

This post has been edited by Omion: Feb 12 2006, 10:49


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
jaybeee
post Feb 12 2006, 11:03
Post #91





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



QUOTE (Omion @ Feb 9 2006, 06:35 AM)
That sounds like what Firon's problem on post 55 was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else wink.gif
*

Sorry for not getting back earlier.
Thought I'd let you know the outcome since you'll be looking at v0.10 soon.

If I update any of the tags (actually deleted a couple) in foobar, then it works ok. So, seems it's the same problem as you mentioned. However, when I then run mp3packer I get this:

Command run: mp3packer.pl -M 40 -a -vbr

Output from mp3packer:
CODE
Processing file '1.mp3' (Source bitrate: 320)
Using in-memory processing.
Output file is CBR 320
11147 frames in 11648161 bytes
Finished processing file.


Foobar properties of 1.mp3:
CODE
bitrate = 320
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
codec = MP3
   --------------------
12838511 samples @ 44100Hz
(rounded samples : 12838392)
Length: 4:51.122


Foobar properties of 1-vbr.mp3:
CODE
enc_delay = 0
enc_padding = 0
mp3_accurate_length = yes
bitrate = 320
codec = MP3
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
   --------------------
12840815 samples @ 44100Hz
(rounded samples : 12840744)
Length: 4:51.174




All fine so far, but...
1-vbr.mp3 when put into mp3packer shows the file is 56kbps CBR!
1-vbr.mp3 is displayed as 56kbps CBR by AudioShell 1.1 and the length as 27:43
1-vbr.mp3 is displayed as 56kbps CBR by Mr QuestionMan v0.701 and the length as 27:44
1-vbr.mp3 is displayed as 56kbps CBR by Mp3tag v2.35 and length as 27:52

Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct. Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
kevinsham
post Feb 12 2006, 11:25
Post #92





Group: Members
Posts: 47
Joined: 23-April 02
Member No.: 1856



QUOTE (Omion @ Feb 12 2006, 05:34 PM)
QUOTE (kevinsham @ Feb 12 2006, 02:11 AM)
It seems that mp3packer is chopping the file.
*

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:
CODE
#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)


I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.
*




This fix has a side effect: the line 866 error is gone too!
Go to the top of the page
+Quote Post
UED77
post Feb 12 2006, 20:10
Post #93





Group: Members
Posts: 41
Joined: 12-February 06
Member No.: 27709



Okay, I commented out line 804, like you suggested. The cause of my first problem was probably Audacity's dithering, as foobar2000's bitcompare says the two files's outputs are identical -- albeit of different lengths. Commenting out the line fixes this problem.

As for the second problem issue, commenting out the line seems to fix this too.

Thanks for your help, and keep up the great work!

UED77


--------------------
UED77
wavpack 4.50 -hx3; lame 3.97 -V4 --vbr-new
Go to the top of the page
+Quote Post
Omion
post Feb 12 2006, 21:02
Post #94





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



QUOTE (jaybeee @ Feb 12 2006, 03:03 AM)
Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct.  Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.
*

I think I might know the problem. mp3repacker uses a small frame for the XING header (unless the -b option is given) That space is reserved before the file is written. However, the file that you have was repacked to a CBR file, so the small XING frame says it's CBR. I guess programs see that and think it's actually 56kbps CBR. The problem that I see is that the frame is usually a 64kbps frame, so I don't really see why anything would mistake that as 56kbps.

The timing being off is another effect of the bitrate being completely wrong. 56/320 = 4:51/27:44. Fixing the bitrate will fix the timing.

I think I can make sure that the XING tag only says it's CBR if the initial frame is the same bitrate as the rest of them.


PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.

This post has been edited by Omion: Feb 12 2006, 21:13


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
jaybeee
post Feb 12 2006, 21:19
Post #95





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



QUOTE (Omion @ Feb 12 2006, 08:02 PM)
PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.
*
see post post 83 - FhG wink.gif

Thanks for looking at this btw


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
Omion
post Feb 13 2006, 09:27
Post #96





Group: Developer
Posts: 432
Joined: 22-February 04
From: San Diego, CA
Member No.: 12180



0.10 out. Just a bugfix. All the recent gripes should be quelched tongue.gif


--------------------
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
Go to the top of the page
+Quote Post
jaybeee
post Feb 13 2006, 11:16
Post #97





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



QUOTE (Omion @ Feb 13 2006, 08:27 AM)
0.10 out. Just a bugfix. All the recent gripes should be quelched tongue.gif
*

Many thanks Omion.

I reckon that for most peeps using your prog to reduce the size of files and thus make vbr files, it will be done on non-LAME mp3s. Cos most peeps that use LAME will probably use vbr or cbr 192kbps. Thus, the mp3 files might not be created in the nicest way... just like the file that I'm having problems with, and as you said yourself (via PM). Just goes to show how good LAME really is.


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
kevinsham
post Feb 13 2006, 14:21
Post #98





Group: Members
Posts: 47
Joined: 23-April 02
Member No.: 1856



A feature request:
Rename the original file and use the input file name as output.
Go to the top of the page
+Quote Post
jaybeee
post Feb 13 2006, 14:28
Post #99





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



QUOTE (kevinsham @ Feb 13 2006, 01:21 PM)
A feature request:
Rename the original file and use the input file name as output.
*
Ah yes.
As in: shove '-orig' on the end of the original input file, and thus the resulting output file can have the original's original name (follow me!?).


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
MuncherOfSpleens
post Feb 13 2006, 20:27
Post #100





Group: Members
Posts: 109
Joined: 25-October 05
From: Florida
Member No.: 25360



Hmm, when using this I get the error message "Can't locate object method 'close' via package 'mp3' (perhaps you forgot to load 'mp3'?) at mp3packer.pl line 171." It will still work when just using the command prompt, but the frontend will cancel the process (or something, it stops and deletes the output file). I was hoping version 0.10 would fix this (I've only had trouble with version 0.9 and now 0.10). Any idea what's wrong?

This post has been edited by MuncherOfSpleens: Feb 13 2006, 20:31
Go to the top of the page
+Quote Post

24 Pages V  « < 2 3 4 5 6 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 06:46