Mobi2Mobi Mobi2Mobi v0.13 - GUI for Mobiperl tools

[DiapDealer]

Originally Posted by tompe

So the idea was that the one include should be used and looking at the code it seem to be used if running the Perl source. Strangely anough it seems not to be used in the packed Windows binary.

I'm getting the "bogus database name" error when using the Windows binary (v0.0.43) AND when running from source on my Linux machine.

I can also verify that commenting out the nul term check allows mobi2mobi to work on this particular title. After being converted by calibre.

[tompe]

Originally Posted by DiapDealer

I'm getting the "bogus database name" error when using the Windows binary (v0.0.43) AND when running from source on my Linux machine.

I can also verify that commenting out the nul term check allows mobi2mobi to work on this particular title. After being converted by calibre.

Strange. I thought that:

use FindBin qw($RealBin);
use lib "$RealBin";

Would make sure that the Palm files included in the distribution was used.

[adriantc]

Originally Posted by tompe

Strange. I thought that:

use FindBin qw($RealBin);
use lib "$RealBin";

Would make sure that the Palm files included in the distribution was used.

So where is the problem... in Mobi2Mobi or Calibre?

[DiapDealer]

Originally Posted by adriantc

So where is the problem... in Mobi2Mobi or Calibre?

I'm just not sure. The source (for the most recent version of calibre) that writes the Palmdoc header seems pretty straightforward and would appear to always create a database name that is 32 characters or less and null terminated.

title = str(self._oeb.metadata.title[0])
title = re.sub('[^-A-Za-z0-9]+', '_', title)[:31]
title = title + ('\0' * (32 - len(title)))

So either:
A) something screwy is happening in calibre that causes the null termination to fail on longer titles.

B) mobi2mobi doesn't think the string is null terminated for some reason.

To be perfectly honest... neither seem very likely to me. I'm a little stymied.

[tompe]

Originally Posted by DiapDealer

I'm just not sure. The source (for the most recent version of calibre) that writes the Palmdoc header seems pretty straightforward and would appear to always create a database name that is 32 characters or less and null terminated.

title = str(self._oeb.metadata.title[0])
title = re.sub('[^-A-Za-z0-9]+', '_', title)[:31]
title = title + ('\0' * (32 - len(title)))

So either:
A) something screwy is happening in calibre that causes the null termination to fail on longer titles.

B) mobi2mobi doesn't think the string is null terminated for some reason.

To be perfectly honest... neither seem very likely to me. I'm a little stymied.

Just look at the example file and see if there is a 0 at position 32 or less.

Maybe the title contains unicode characters?

[adriantc]

Originally Posted by tompe

Just look at the example file and see if there is a 0 at position 32 or less.

Maybe the title contains unicode characters?

No it doesn't... he title is straightforward... The Demon-Haunted World: Science as a Candle in the Dark

[DiapDealer]

Originally Posted by tompe

Just look at the example file and see if there is a 0 at position 32 or less.

Maybe the title contains unicode characters?

No unicode on my end. I just manually typed the title in question to be sure (in case copy paste was doing something weird).

With these really long titles, calibre appears to be filling the entire database name string with 32 characters from the title. The NUL doesn't occur until position 33:

The_Demon-Haunted_World__Science\x00

That's two underscores between 'World' and 'Science'. With shorter names, the NUL appears at position 32 or less.

It definitely seems like a calibre issue to me... IF it can be verified that a NUL is definitely supposed to be in the 32nd position (or less) of a valid Palmdoc header.

EDIT: Many Kindle books no longer have a Palm DB Name, so I can't compare with one of theirs. The only Kindle book I have with a title longer than 32 characters doesn't have a Database name.

[adriantc]

Originally Posted by DiapDealer

No unicode on my end. I just manually typed the title in question to be sure (in case copy paste was doing something weird).

With these really long titles, calibre appears to be filling the entire database name string with 32 characters from the title. The NUL doesn't occur until position 33:

The_Demon-Haunted_World__Science\x00

That's two underscores between 'World' and 'Science'. With shorter names, the NUL appears at position 32 or less.

It definitely seems like a calibre issue to me... IF it can be verified that a NUL is definitely supposed to be in the 32nd position (or less) of a valid Palmdoc header.

EDIT: Many Kindle books don't no longer have a Palm DB Name, so I can't compare with one of theirs. The only Kindle book I have with a title longer than 32 characters doesn't have a Database name.

Could you please tell me with what software do you read them?

EDIT: Just got a reply from Kovid Goyal:

There is no requirement that it be terminated by a NULL. That field is
reserved at 32 characters. If the title is shorter than 32 characters, it is
padded by nulls. If it is 32 chars or more, it is trucated to 32 chars, in
which case it is not NULL terminated.

EDIT: And another reply from Kovid Goyal:

However, in the interests of not causing unneccessary breakage, I'll change
calibre to limit the title to 31 chars so that the 32nd will always be zero
terminated.

He said the fix will be implemented in Friday's release.

[DiapDealer]

Hey, at least we figured out what was going on.

Gotta respect Kovid for making a change like that—since technically it wasn't even a calibre issue. Luckily, the Db name isn't really that critical to most devices/apps anymore. Like I said, A lot of Amazon's ebooks don't even have one.

[adriantc]

Originally Posted by DiapDealer

Hey, at least we figured out what was going on.

Gotta respect Kovid for making a change like that—since technically it wasn't even a calibre issue. Luckily, the Db name isn't really that critical to most devices/apps anymore. Like I said, A lot of Amazon's ebooks don't even have one.

Yeah... We do have to appreciate him. A small donation is in order. Just last week he fixed another bug I noticed.

[tompe]

The text at

https://wiki.mobileread.com/wiki/PDB#...atabase_Format

is kind of ambiguous about if it should be always null terminated or not. It says:

database name. This name is 0 terminated in the field and will be used as the file name on a computer. For eBooks this usually contains the title and may have the author depending on the length available.

[Khan-Dam]

Hi,

I discover Mobi2Mobi GUI since i had my kindle ( for 1 Week ) i use it to change some tags in my mobi file. but i have some remarks about this tool specialy when i use it with calibre.

I must have my mobi in one folder, calibre explode all in multi-folder.
I must use open button to load mobi info, there are some improvement to work with calibre correctly i think.

So i obtain vb sources and change some little line in source to add the possibility to pass filepath of the book in command line, show the error when mobi2mobi.exe can't open file. the last thing i change is to add special field for handling ECTH 503 ( there is this my kindle use for book name ) and each time i must unroll the combo to shox exth 503 and retype the value, with this modification i can handle simply this field.

now i can directly use from calibre open with menu to open mobi file - with the restrication about 32 char in databasename and 0x00 terminated

I don't know who maintain the source but if you want i can provide the modifycations i work with the version 10. or where must i send them

second thing is it possible to obtain mobi2mobi sources ?

sorry for my english but it's not my birth language

Khan-dam

[DiapDealer]

Originally Posted by Khan-Dam

second thing is it possible to obtain mobi2mobi sources ?

mobi2mobi is part of the MobiPerl tools. They're just Perl scripts/libraries—some of which have been compiled for Windows so users don't have to install Perl and track down all the dependencies themselves.

You can download the latest source for all of the MobiPerl command-line tools from here: https://dev.mobileread.com/dist/tompe/mobiperl/.

[Bismar]

Hi,

I'm having issue with the mobi2mobi [filename], particulary in relation to its output being a binary or text file.

Using grep on mobi2mobi [filename], i get at times,

Author is Binary file (standard input) matches, and Title is e (standard input) matches

where the bolded parts is the method returns. Conversion of files was done with the same calibre settings

Edi: for some reason, the carriage return doesn't exist after the author line for some files :/

[Peter 1977]

It would be nice to see a dictionary option added to this program as with the kindle touch there is less flexibility over selecting the dictionary and publishers are putting them under the wrong language. In the past with other kindle this did not matter. I have one here that i had to unpack, adjust and then it wouldnt repack due to utf-8 errors, its much easier to go in directly and adjust it.

It would also be nicer to see more lanagauge in the language list as this list is more important now too, I see spanish wasnt listed and had to set it as neutal and hope it used the correct dictionary. In addition to adding spanish maybe you could add a manual entry and provide a list of codes etc for this. I see there have been no updates for a long time, has a new program superseded this?