Develop Reference

Split a zip file into multiple files files using java [duplicate]

This question already has answers here:
How to break a file into pieces using Java?
(2 answers)
Closed 11 months ago.
Hello I need to split a zip file into multiple samaller files,
ex. file.zip is splitted into files with fixed size less than 640MB and format nameOfZip.zip.001
I am currently looking for some kind of a java library that would be able to do this. If there is no such, advice would be very helpful too.

Zip, the format, can do this. You can then unzip the batch of files with plain jane unzip on the command line (or with tools like p7zip and such, or you can just doubleclick the zip on a mac, etcetera).
Unfortunately, the baked in zip support in java can't make split zips. But, Lingala / Zip4j can do it.
Add that library to your list of dependencies and use its API (forget about java.io.ZipOutputStream, or the Zip FileSystem - anything that starts with java.* can't do this.
Alternatively it is trivial to write code in java to just split any file. You'd need to write java code as well to put them back together, or you need to know a few things about your OS to do this (e.g. cat a.bin b.bin >c.bin on posix OSes will put a.bin and b.bin back together). This isn't difficult at all, just your basic file and outputstream support can trivially put it together in less than a page's worth of java code. No libraries exist, and probably never will - that is a very simple task that isn't common enough to make a library for.
So, if that's what you're looking for, go ahead and write it yourself. All you need is the javadoc of java.nio.file.Paths and java.nio.file.Files.

How do I edit .mca files from Minecraft?

Introduction
I want to combine my separate Minecraft worlds into a single world and it seemed like a relatively easy feat, but as I did research it evolved into the need to make a custom program.
The Struggle
I started by shifting the region files and combining them in one region folder, which seemed like the obvious solution and it almost worked. Note: I've opened the files and it seems entire sectors have their coordinates stored, not entities, hence the terrain itself is spatially mismatched with the region file name.
That led to quite a bit of lag when I opened the client and the regions failed to render. I read up on the Anvil file format and imagined a scheme for reading NBT files. I figured I could manually read out the bytes and edit them, but in my continued research I got conflicting answers as to whether region files are gzipped.
I finished enough code to read some raw bytes, but the byte values didn't come out as I expected.
According to the info I have on NBT files, they all start with a CompoundTag and a CompoundTag starts as a single byte valued as 10, or x0A.
This is where I got my format information: https://minecraft.gamepedia.com/NBT_format
Here's a screenshot of what actually came out:
Note: The class description in the screenshot is not accurate. I just quickly filled in enough to read the bytes, not flesh out the UI function.
I assume these bytes coming out as non-sense is a sign that the file is compressed. I found this as a start to the gzip problem:
http://gnuwin32.sourceforge.net/packages/gzip.htm
I imagine if I could get this installed it would unzip this .mca file and I could read the bytes as expected, but I don't understand the installation instructions. It says use the "Shell Commands, 'configure', 'make' and 'make install'". To me that sounds like Unix, but the file I downloaded is for Windows? There aren't any exe's, but there are quite a few C files. I don't have a C-compiler. . .
Note: I still have not got the gzip software to work.
Post Script
I've seen similar questions asked here, but all of them were either old (2016ish) with dead links to software that used to work, or they were recent and unanswered. I found one specific copy of this question asked 5 months ago, but I had to make an account to comment. Here's the link: How can read Minecraft .mca files so that in python I can extract individual blocks? His question is with regard to a Python implementation. He said he found an NBT library for Python, but it was rejecting his MCA files for being not-gzipped.
I've got a lead on understanding the problem because I have the NBTExplorer source code (see the answer I posted), but I'll have to update on how that pans out. As far as getting my world fixed, I think I have a viable solution now.
If anyone could point me to a finished Java library, with source code, that opens .mca's or a discussion board related to this topic that'd be cool. I'm still also interested in how file compression works, but that's probably outside this question's scope. I realize this isn't directly bug or error related; it's it was moreso that I didn't know what further steps to take to make a code that accomplishes this task.
Update
I found someone else's program to do this and posted it as an answer, but I'd still like to know how the file is converted from bytes to useable info. Using the manual edit method of the answer I posted, I will need at most 241,664 manual edits, so I still need a better solution.

First of: As far as I know there is no more information about "where the chunks are", stored in the region files. There are 32(x direction)*32(z-direction)= 1024 Chunks stored within one region file and each of it has its position of data within the file. So the chunks are just numbered within the file itself and the first 8192 bytes are just about if there is any data about that specific chunk or not, where its found within the file and when it got last updated. Where the complete region (those 1024 Chunks) are positioned within the world can be worked out within the file name where the regions themself are numbered in x and z direction.
So in your case you should be able to rename your region files in a way they stay togehter as they are in the original worlds and you should be able to merge them together.
Second: The NBT Format is not the first thing to look at when you want to decode the data. First of the Region files have their own structure: https://minecraft.gamepedia.com/Region_file_format and when you get to the actual data using Zlib (RFC1950) it's getting complicated...
Anyway if you want further information on how to decode I can give you some information (since the files https://www.rfc-editor.org/rfc/rfc1950.html and https://www.rfc-editor.org/rfc/rfc1951 about Zlib (RFC1950) are written in a hard way to understand - at least it was for me). But theres a point where I myself am struggeling right now which is why I came across this question.

I found an editor!
Now I can edit, but I don't know how the editing works. I haven't learned anything, but I did finally find someone else's editor. Not quite what I wanted because I wanted to know how to do this myself.
Update: To fix a region using this software I have to manually edit 2 fields, for up to 32x32 chunks, and I have 118 regions that I need to fix. **That's 241,664 potential manual edits! This solution is not viable on a reasonable timescale, but it's the best I have so far:
I found this page: https://fileinfo.com/extension/mca
Which linked to this page: https://fileinfo.com/software/nbtexplorer/nbtexplorer
Which linked to this page: https://github.com/jaquadro/NBTExplorer/releases
I installed the software and it automatically linked to the .minecraft folder, here's a screenshot of the GUI:
On the bright side, the application download page also has a download link for the source, so I intend to read that! I've opened two files so far to take a glance and they were not commented at all. They're also written in C# which I have never seen before, but I've heard it's very similar to Java, so maybe I'll learn that language too.

This Java library is quite nice for editing .mca and has some examples of doing so in the README
https://github.com/Querz/NBT
As for how the compression works, chunks can be individually compressed via either gzip or zlib, but in practice are generally all zlib compressed, which is implemented in Java through Inflater and Deflater. One annoying thing about the format for chunk data is it is only prefixed with the size of the compressed buffer, with no info on the size of the uncompressed buffer (so the uncompressed buffer must be estimated to be large enough or multiple buffers can be used to fill until the compressed buffer is completely "inflated").

How to Create a .dst Embroidery File using Java

I want to create a .dst embroidery file using Java. Are there any supporting libraries available? Or is it possible to convert any kind of image file to the .dst embroidery file format using Java?
Can anyone suggest any algorithms, encoding-decoding methods, etc?

I am the developer at Embroidermodder working on formats (the link mentioned by theJollySin).
I don't have any Java code, but I can point you to some preliminary documentation of the format (http://www.achatina.de/sewing/main/TECHNICL.HTM).
What are you trying to create in DST? I can assist you with whatever issues you have getting your Java code running.

The short answer to your question is, no. There are currently no popular libraries for generating .dst embroidery files with Java. My guess is that you will have a lot more luck trying to convert other file types to the .dst formats. The only option there (that I know of) is Corel Draw.
In the end, the best solution I can think of is to use the Tajima Ambaasador website. You have to register, but I believe most of their design/DST services are free.
(After some searching around online I also found this website, which has some more free software and seems like the best place to start if you're looking for information.)

Yes. I've written exactly such a library for python (pyembroidery) and trancoded that to java. It will work for both Android and Oracle Java and has fully fleshed out reading and writing of most major embroidery formats.
https://github.com/EmbroidePy/EmbroideryIO
As part of a parallel project I've also done a considerable amount of work documenting various formats for a wiki on the topic. Located here:
https://edutechwiki.unige.ch/en/Embroidery_format
Which also has all the known technical details for DST file formats:
https://edutechwiki.unige.ch/en/Embroidery_format_DST
As for the second part of the question, embroidery files are vector-like files which provides a series of commands to be issued to an embroidery machine. You cannot directly convert raster-based image files to embroidery because the pixel information does not directly convert to any sort of embroidery machine command instruction structure.

Concatenating mp3 files in android [duplicate]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've got many, many mp3 files that I would like to merge into a single file. I've used the command line method
copy /b 1.mp3+2.mp3 3.mp3
but it's a pain when there's a lot of them and their namings are inconsistent. The time never seems to come out right either.

David's answer is correct that just concatenating the files will leave ID3 tags scattered inside (although this doesn't normally affect playback, so you can do "copy /b" or on UNIX "cat a.mp3 b.mp3 > combined.mp3" in a pinch).
However, mp3wrap isn't exactly the right tool to just combine multiple MP3s into one "clean" file. Rather than using ID3, it actually inserts its own custom data format in amongst the MP3 frames (the "wrap" part), which causes issues with playback, particularly on iTunes and iPods. Although the file will play back fine if you just let them run from start to finish (because players will skip these is arbitrary non-MPEG bytes) the file duration and bitrate will be reported incorrectly, which breaks seeking. Also, mp3wrap will wipe out all your ID3 metadata, including cover art, and fail to update the VBR header with the correct file length.
mp3cat on its own will produce a good concatenated data file (so, better than mp3wrap), but it also strips ID3 tags and fails to update the VBR header with the correct length of the joined file.
Here's a good explanation of these issues and method (two actually) to combine MP3 files and produce a "clean" final result with original metadata intact -- it's command-line so works on Mac/Linux/BSD etc. It uses:
mp3cat to combine the MPEG data frames only into a continuous file, then
id3cp to copy all metadata over to the combined file, and finally
VBRFix to update the VBR header.
For a Windows GUI tool, take a look at Merge MP3 -- it takes care of everything. (VBRFix also comes in GUI form, but it doesn't do the joining.)

As Thomas Owens pointed out, simply concatenating the files will leave multiple ID3 headers scattered throughout the resulting concatenated file - so the time/bitrate info will be wildly wrong.
You're going to need to use a tool which can combine the audio data for you.
mp3wrap would be ideal for this - it's designed to join together MP3 files, without needing to decode + re-encode the data (which would result in a loss of audio quality) and will also deal with the ID3 tags intelligently.
The resulting file can also be split back into its component parts using the mp3splt tool - mp3wrap adds information to the IDv3 comment to allow this.

Use ffmpeg or a similar tool to convert all of your MP3s into a consistent format, e.g.
ffmpeg -i originalA.mp3 -f mp3 -ab 128kb -ar 44100 -ac 2 intermediateA.mp3
ffmpeg -i originalB.mp3 -f mp3 -ab 128kb -ar 44100 -ac 2 intermediateB.mp3
Then, at runtime, concat your files together:
cat intermediateA.mp3 intermediateB.mp3 > output.mp3
Finally, run them through the tool MP3Val to fix any stream errors without forcing a full re-encode:
mp3val output.mp3 -f -nb

The time problem has to do with the ID3 headers of the MP3 files, which is something your method isn't taking into account as the entire file is copied.
Do you have a language of choice that you want to use or doesn't it matter? That will affect what libraries are available that support the operations you want.

MP3 files have headers you need to respect.
You could ether use a library like Open Source Audio Library Project and write a tool around it.
Or you can use a tool that understands mp3 files like Audacity.

What I really wanted was a GUI to reorder them and output them as one file
Playlist Producer does exactly that, decoding and reencoding them into a combined MP3. It's designed for creating mix tapes or simple podcasts, but you might find it useful.
(Disclosure: I wrote the software, and I profit if you buy the Pro Edition. The Lite edition is a free version with a few limitations).

As David says, mp3wrap is the way to go. However, I found that it didn't fix the audio length header, so iTunes refused to play the whole file even though all the data was there. (I merged three 7-minute files, but it only saw up to the first 7 minutes.)
I dug up this blog post, which explains how to fix this and also how to copy the ID3 tags over from the original files (on its own, mp3wrap deletes your ID3 tags). Or to just copy the tags (using id3cp from id3lib), do:
id3cp original.mp3 new.mp3

I would use Winamp to do this. Create a playlist of files you want to merge into one, select Disk Writer output plugin, choose filename and you're done. The file you will get will be correct MP3 file and you can set bitrate etc.

I'd not heard of mp3wrap before. Looks great. I'm guessing someone's made it into a gui as well somewhere. But, just to respond to the original post, I've written a gui that does the COPY /b method. So, under the covers, nothing new under the sun, but the program is all about making the process less painful if you have a lot of files to merge...AND you don't want to re-encode AND each set of files to merge are the same bitrate. If you have that (and you're on Windows), check out Mp3Merge at: http://www.leighweb.com/david/mp3merge and see if that's what you're looking for.

If you want something free with a simple user interface that makes a completely clean mp3 I recommend MP3 Joiner.
Features:
Strips ID3 data (both ID3v1 and ID3v2.x) and doesn't add it's own (unlike mp3wrap)
Lossless joining (doesn't decode and re-encode the .mp3s). No codecs required.
Simple UI (see below)
Low memory usage (uses streams)
Very fast (compared to mp3wrap)
I wrote it :) - so you can request features and I'll add them.
Links:
MP3 Joiner website: Here
Latest installer: Here

Personally I would use something like mplayer with the audio pass though option eg -oac copy

Instead of using the command line to do
copy /b 1.mp3+2.mp3 3.mp3
you could instead use "The Rename" to rename all the MP3 fragments into a series of names that are in order based on some kind of counter. Then you could just use the same command line format but change it a little to:
copy /b *.mp3 output_name.mp3
That is assuming you ripped all of these fragment MP3's at the same time and they have the same audio settings. Worked great for me when I was converting an Audio book I had in .aa to a single .mp3. I had to burn all the .aa files to 9 CD's then rip all 9 CD's and then I was left with about 90 mp3's. Really a pain in the a55.

PDF to PCL conversion

In my Java application, I have PDF files that I eventually need to convert to PCL and send to a RightFax server. I'll also need to embed codes in the PCL files that RightFax will read to know where to send the fax.
What's the best approach towards doing this?
Searching online, it seems like I could use Java's StreamPrintService to print the PDF files to PCL. Is this correct? Does this also mean that I must have installed on my OS a printer that can interpret PCL?
Once the PCL file is generated, I need to add the embedded codes in the file. Do I add the codes to the end of the file (by opening it in Java and writing out to it)?

The simplies solution, IMHO, is to drop the PDF into a folder on the RightFax server. Then create a small text file with all the instructions for who to send the document to etc. using Embedded Codes or FCL (Fax Command Language). We do this all of the time and it works great. Note: Fax Command Languate is only available if you have the Integration Module. Both Embedded Codes and FCL each have a command to attach a file(s). Once RightFax receives this text file it will process the commands and attach the PDF and fax and/or email the document. Here are two examples (one Embedded and one FCL).
Embedded Code File:
<TOFAXNUM:999999999>
<TONAME:Douglas Anderson>
<BILLINFO1:12345>
<NOCOVER>
<WHO:DOUG>
<ADDDOC2: C:\pdfFiles\12345.pcl>
FCL Code File:
{{begin}}
{{fax 999999999}}
{{contact Douglas Anderson}}
{{billinfo1 12346}}
{{nocover}}
{{attach C:\pdfFiles\12345.pcl delete}}
{{imagetype pdf}}
{{end}}
Sending this simple text file to RightFax will prompt it to process and insert the document you specify. There are vaious ADDDOC commands and switchinges for ATTACH that tell RightFax to delete the file once it has been sent etc.
The Embedded Code File can be sent in via the HPFAX queue and the FCL can be sent in via the Production Inbox (c:\program files\rightfax\production\inbox).
This gives a lot of control and allows for easier troubleshooting as you still have a PDF that is viewable (due to the fact that you didn't stick text at the start of it), and you can easily output the Embedded Code or FCL files to an alternate folder for viewing and even modifying with simple tools like Notepad.
Edit: OpenSource is correct that you can concatenate files together, I haven't done this with Embedded Codes for a long time (see example at end) but have done something similar with FCL (if you have the Ingetration Module you can do this).
FCL with PDF or Postscript embedded in data (RightFax treats PS and PDF):
{{begin}}
{{fax 999999999}}
{{contact Douglas Anderson}}
{{billinfo1 12346}}
{{nocover}}
{{beginpostscript}}
%PDF-1.3...
...your pdf...
{{endpostscript}}
{{end}}
The PCL variant looks like this:
{{begin}}
{{fax 999999999}}
{{contact Douglas Anderson}}
{{billinfo1 12346}}
{{nocover}}
{{beginpcl}}
...your pcl data...
{{endpcl}}
{{end}}
False first page with Embedded Codes (as per my notes from something we did a long time ago):
<TOFAXNUM:999999999>
<TONAME:Douglas Anderson>
<BILLINFO1:12345>
<NOCOVER>
<WHO:DOUG>
<DELETEFIRSTPAGE>
*PCL formfeed character*
...your pcl data...
Whatever you send will appear on the 'first page' but this will be deleted. The other option is to send this data after the Formfeed a the end of the document and use the <DELETELASTPAGE> option. This data can also appear inline with the PCL file itself and as such you may be able to send it at the start of the job without the <DELETEFIRSTPAGE> command and the formfeed splitter.

We have a very similar process. What we do is we have a pcl file and a control file (a text file with the rightfax instructions in it). We concatenate these two files using java NIO and send it across to the rightfax print queue. We basically create a new file and write the above two into the new file using the transferFrom() method in the channel which is got by stream.getChannel(). We put control instructions at the top not at the bottom as you have mentioned? may be you misstated it - I think Rightfax needs it at the top. I have to admit I have not tried to send it at the bottom. May be it will work just dont know.

JPS lets you print to file so you just need to print to file on a PCL printer.

print-to-file seems to be the right approach here.